idnits 2.17.1 draft-ietf-dime-qos-attributes-03.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 656. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 663. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 669. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 6004 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) == Missing Reference: 'EAP-Master-Session-Key' is mentioned on line 354, but not defined == Missing Reference: 'QoS-desired' is mentioned on line 505, but not defined == Missing Reference: 'QoS-Authorized' is mentioned on line 508, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-radext-filter-rules' ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-01 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and J. Korhonen, Ed. 3 Extensions (DIME) TeliaSonera 4 Internet-Draft H. Tschofenig 5 Intended status: Standards Track Nokia Siemens Networks 6 Expires: May 21, 2008 M. Arumaithurai 7 University of Goettingen 8 M. Jones 9 Bridgewater Systems 10 November 18, 2007 12 Quality of Service Attributes for Diameter 13 draft-ietf-dime-qos-attributes-03.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 21, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document extends the QoSFilterRule AVP functionality of the 47 Diameter Base protocol and the functionality of the QoS-Filter-Rule 48 AVP defined in RFC 4005. The ability to convey Quality of Service 49 information using the AVPs defined in this document is available to 50 existing Diameter applications where permitted by the command ABNF 51 and to all new applications. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Diameter QoS Defined AVPs . . . . . . . . . . . . . . . . . . 3 58 3.1. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 3 59 3.2. QoS-Profile-Template AVP . . . . . . . . . . . . . . . . . 4 60 3.3. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 4 61 3.4. Extended-QoS-Filter-Rule AVP . . . . . . . . . . . . . . . 5 62 3.5. QoS-Profile AVP . . . . . . . . . . . . . . . . . . . . . 5 63 3.6. QoS-Profile-ID AVP . . . . . . . . . . . . . . . . . . . . 5 64 3.7. QoS-Semantics . . . . . . . . . . . . . . . . . . . . . . 5 65 3.8. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 6 66 3.9. QoS-Flow-State AVP . . . . . . . . . . . . . . . . . . . . 6 67 3.10. QoS-Flow-Direction AVP . . . . . . . . . . . . . . . . . . 6 68 4. Semantics of QoS Parameters . . . . . . . . . . . . . . . . . 7 69 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Diameter EAP with QoS Information . . . . . . . . . . . . 8 71 5.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 9 72 5.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 10 73 5.4. Diameter Server Initiated Re-authorization of QoS . . . . 11 74 5.5. Diameter Credit Control with QoS Information . . . . . . . 12 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Intellectual Property and Copyright Statements . . . . . . . . . . 16 84 1. Introduction 86 This document defines a number of Diameter Quality of Service (QoS) 87 related AVPs that can be used in existing Diameter applications where 88 permitted by the command ABNF and in all new applications. The 89 Extended-QoS-Filter-Rule AVP thereby replaces the QoSFilterRule, 90 defined in RFC 3588 [RFC3588], and the QoS-Filter-Rule, defined in 91 RFC 4005 [RFC4005]. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 3. Diameter QoS Defined AVPs 101 The following table lists the Diameter AVPs used by this document, 102 their AVP code values, types, possible flag values, and whether the 103 AVP may be encrypted. 105 +------------------+ 106 | AVP Flag Rules | 107 +-------------------------------------------------|----+---+----+----+ 108 | AVP Section |MUST|MAY|SHLD|MUST| 109 | Attribute Name Code Defined Data Type | | | NOT| NOT| 110 +-------------------------------------------------+----+---+----+----+ 111 |QoS-Capability TBD 3.1 Grouped | |M,P| | V | 112 |QoS-Profile-Template TBD 3.2 Unsigned64 | |M,P| | V | 113 |QoS-Resources TBD 3.3 Grouped | |M,P| | V | 114 |Extended-QoS-Filter-Rule TBD 3.4 Grouped | |M,P| | V | 115 |QoS-Profile TBD 3.5 Grouped | |M,P| | V | 116 |QoS-Profile-ID TBD 3.6 Unsigned32 | |M,P| | V | 117 |QoS-Semantics TBD 3.7 Enumerated | |M,P| | V | 118 |QoS-Parameters TBD 3.8 OctetString| |M,P| | V | 119 |QoS-Flow-State TBD 3.9 Enumerated | |M,P| | V | 120 |QoS-Flow-Direction TBD 3.10 Enumerated | |M,P| | V | 121 +-------------------------------------------------+----+---+----+----+ 123 3.1. QoS-Capability AVP 125 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 126 a list of supported Quality of Service profile templates (and 127 therefore the support of the respective parameter AVPs). 129 QoS-Capability ::= < AVP Header: XXX > 130 1* { QoS-Profile-Template } 131 * [ AVP ] 133 3.2. QoS-Profile-Template AVP 135 The QoS-Profile-Template AVP (AVP Code TBD) is of type Unsigned64 and 136 contains the vendor and a specifier field. The 64-bit value in the 137 QoS-Profile-Template AVP is structured as shown below. 139 0 1 2 3 140 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Vendor | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Specifier | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Vendor Field: 149 32 bits of IANA SMI Network Management Private Enterprise Code. 150 The Vendor-ID 0x00000000 is reserved for IANA registered QoS 151 profiles. 153 Specifier Field: 155 32-bit unsigned integer, representing the defined profile value. 157 An initial QoS profile template is defined with vendor field set to 158 0x00000000 and the specifier field set to 0, as described in 159 [I-D.ietf-dime-qos-parameters]. The registry for the QoS profile 160 templates is created with the same document. 162 3.3. QoS-Resources AVP 164 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and includes 165 a description of the Quality of Service resources for policing 166 traffic flows. 168 QoS-Resources ::= < AVP Header: XXX > 169 0* [ Extended-QoS-Filter-Rule ] 170 [ QoS-Profile ] 171 [ QoS-Flow-State ] 172 * [ AVP ] 174 3.4. Extended-QoS-Filter-Rule AVP 176 The Extended-QoS-Filter-Rule AVP (AVP Code TBD) is of type Grouped 177 and defines one or more traffic flows together with the QoS profile 178 that should be applied to the flow(s) by the Resource Management 179 Function. This AVP re-uses the RADIUS NAS-Traffic-Rule AVP 180 [I-D.ietf-radext-filter-rules] to describe traffic flows. The 181 Extended-QoS-Filter-Rule AVP ties a specific traffic filter to a QoS- 182 Profile-ID that in turn refers to a specific set of QoS parameters. 183 At least either one of the NAS-Traffic-Rule or the QoS-Flow-Direction 184 AVPs SHOULD be included. 186 Extended-QoS-Filter-Rule ::= < AVP Header: XXX > 187 [ QoS-Profile-ID ] 188 [ NAS-Traffic-Rule ] 189 [ QoS-Flow-Direction ] 190 * [ AVP ] 192 3.5. QoS-Profile AVP 194 The QoS-Profile AVP (AVP Code TBD) is of type Grouped and ties the 195 QoS-Profile-ID AVP to a set of QoS-Parameters AVPs. All parameters 196 refer to the same QoS model/profile described by the QoS-Profile- 197 Template AVP. 199 QoS-Profile ::= < AVP Header: XXX > 200 [ QoS-Profile-ID ] 201 { QoS-Semantics } 202 { QoS-Profile-Template } 203 [ QoS-Parameters ] 204 * [ AVP ] 206 3.6. QoS-Profile-ID AVP 208 The QoS-Profile-ID AVP (AVP Code TBD) is of type Unsigned32 and 209 references a set of QoS-Parameters AVPs. 211 3.7. QoS-Semantics 213 The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and 214 provides the semantics for the content of the QoS-Profile AVP. 216 This document defines the following values: 218 (0): QoS-Desired 219 (1): QoS-Available 220 (2): QoS-Reserved 221 (3): Minimum-QoS 222 (4): QoS-Authorized 224 3.8. QoS-Parameters AVP 226 The QoS-Parameters AVP (AVP Code TBD) is of type OctetString and 227 contains Quality of Service parameters. These parameters are defined 228 in a separate document, see [I-D.ietf-dime-qos-parameters]. 230 3.9. QoS-Flow-State AVP 232 The QoS-Flow-State AVP (AVP Code TBD) is of type Enumerated. It 233 gives an indication as to how the flow has to be treated. The 234 Extended-QoS-Filter-Rule already provides an indicate whether a flow 235 is permitted or denied. This optional AVP provides additional 236 information about the treatment. Currently, a single value is 237 defined; further values are available via IANA registration. 239 Value | Name and Semantic 240 ------+------------------------------------------------------------ 241 0 | QOS_FLOW_STATE_PENDING - The QoS reservation is kept 242 | pending. The QoS resources are not installed and subsequent 243 | QoS signaling is necessary to active them. 245 3.10. QoS-Flow-Direction AVP 247 The QoS-Flow-Direction AVP (AVP Code TBD) is of type Enumerated. It 248 gives an indication of the direction the provided QoS information 249 should be applied to. The QoS information can be applied to downlink 250 flows or to uplink flows. The QoS-Flow-Direction AVP may be used in 251 conjunction with the NAS-Traffic-Rule AVP. In a case conflicting 252 definitions between the QoS-Flow-Direction and the NAS-Traffic-Rule, 253 the QoS-Flow-Direction has precedence meaning the filter rules are 254 applied only to the flows going to the direction indicated by the 255 QoS-Flow-Direction AVP. In the absence of the QoS-Flow-Direction the 256 default treatment is to both directions. 258 Value | Name and Semantic 259 ------+------------------------------------------------------------ 260 0 | QOS_FLOW_DIRECTION_BOTH - The QoS information in applied to 261 | both downlink and uplink flows. This is also the default. 262 1 | QOS_FLOW_DIRECTION_DL - The QoS information in applied to 263 | downlink flows only. 264 2 | QOS_FLOW_DIRECTION_UL - The QoS information in applied to 265 | uplink flows only. 267 4. Semantics of QoS Parameters 269 The QoS parameters carried in the QoS-Resources AVP may appear in 270 different messages. The semantic of the QoS parameters depend on the 271 information provided in the QoS-Semantics AVP which currently defines 272 5 values, namely QoS-Desired (0), QoS-Available (1), QoS-Reserved 273 (2), Minimum-QoS (3), and QoS-Authorized (4). 275 The semantics of the different values are as follows: 277 Object Type Direction Semantic 278 ---------------------------------------------------------------------- 279 QoS-Desired C->S Please authorize the indicated QoS 280 QoS-Desired C<-S NA 281 QoS-Available C->S Admission Control at router indicates 282 that this QoS is available. (note 1) 283 QoS-Available C<-S Indicated QoS is available. (note 2) 284 QoS-Reserved C->S Used for reporting during accounting. 285 QoS-Reserved C<-S NA 286 Minimum-QoS C->S Indicates that the client is not interested 287 interested in authorizing QoS that is 288 lower than Min. QoS 289 Minimum-QoS C<-S The client must not provide QoS guarantees 290 lower than Min. QoS 291 QoS-Authorized C->S NA 292 QoS-Authorized C<-S Indicated QoS authorized 294 Legend: 296 C: Diameter client 297 S: Diameter server 298 NA: Not applicable to this document; 299 no semantic defined in this specification 301 Notes: 303 (1) QoS-Available is only useful in relationship with QoS-Desired 304 (and optionally with Minimum-QoS). 305 (2) QoS-Available is only useful when the AAA server performs 306 admission control and knows about the resources in the network. 308 5. Examples 310 This section shows a number of signaling flows where QoS negotiation 311 and authorization is part of the conventional NASREQ, EAP or Credit 312 Control applications message exchanges. The signalling flows for the 313 Diameter QoS Application are described in 314 [I-D.ietf-dime-diameter-qos]. 316 5.1. Diameter EAP with QoS Information 318 Figure 11 shows a simple signaling flow where a NAS (Diameter Client) 319 announces its QoS awareness and capabilities included into the DER 320 message and as part of the access authentication procedure. Upon 321 completion of the EAP exchange, the Diameter Server provides a pre- 322 provisioned QoS profile with the QoS-Semantics in the QoS-Profile AVP 323 set to "QoS-Authorized", to the NAS in the final DEA message. 325 End Diameter Diameter 326 Host Client server 327 | | | 328 | (initiate EAP) | | 329 |<------------------------------>| | 330 | | Diameter-EAP-Request | 331 | | EAP-Payload(EAP Start) | 332 | | QoS-Capability | 333 | |------------------------------->| 334 | | | 335 | | Diameter-EAP-Answer | 336 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 337 | | EAP-Payload(EAP Request #1) | 338 | |<-------------------------------| 339 | EAP Request(Identity) | | 340 |<-------------------------------| | 341 : : : 342 : <<>> : 343 : : : 344 | | | 345 | EAP Response #N | | 346 |------------------------------->| | 347 | | Diameter-EAP-Request | 348 | | EAP-Payload(EAP Response #N) | 349 | |------------------------------->| 350 | | | 351 | | Diameter-EAP-Answer | 352 | | Result-Code=DIAMETER_SUCCESS | 353 | | EAP-Payload(EAP Success) | 354 | | [EAP-Master-Session-Key] | 355 | | (authorization AVPs) | 356 | | QoS-Resources(QoS-Authorized) | 357 | |<-------------------------------| 358 | | | 359 | EAP Success | | 360 |<-------------------------------| | 361 | | | 363 Figure 11: Example of a Diameter EAP enhanced with QoS Information 365 5.2. Diameter NASREQ with QoS Information 367 Figure 12 shows a similar pre-provisioned QoS signaling as in 368 Figure 11 but using the NASREQ application instead of EAP 369 application. 371 End Diameter 372 Host NAS Server 373 | | | 374 | Start Network | | 375 | Attachment | | 376 |<---------------->| | 377 | | | 378 | |AA-Request | 379 | |NASREQ-Payload | 380 | |QoS-Capability | 381 | +----------------------------->| 382 | | | 383 | | AA-Answer| 384 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 385 | NASREQ-Payload(NASREQ Request #1)| 386 | |<-----------------------------+ 387 | | | 388 | Request | | 389 |<-----------------+ | 390 | | | 391 : : : 392 : <<>> : 393 : : : 394 | Response #N | | 395 +----------------->| | 396 | | | 397 | |AA-Request | 398 | |NASREQ-Payload ( Response #N )| 399 | +----------------------------->| 400 | | | 401 | | AA-Answer| 402 | | Result-Code=DIAMETER_SUCCESS| 403 | | (authorization AVPs)| 404 | |QoS-Resources(QoS-Authorized) | 405 | |<-----------------------------+ 406 | | | 407 | Success | | 408 |<-----------------+ | 409 | | | 411 Figure 12: Example of a Diameter NASREQ enhanced with QoS Information 413 5.3. QoS Authorization 415 Figure 13 shows an example of authorization only QoS signaling as 416 part of the NASREQ message exchange. The NAS provides the Diameter 417 server with the "QoS-Desired" QoS-Semantics AVP included in the QoS- 418 Resources AVP. The Diameter server then either authorizes the 419 indicated QoS or rejects the request and informs the NAS about the 420 result. In this scenario the NAS does not need to include the QoS- 421 Capability AVP in the AAR message as the QoS-Resources AVP implicitly 422 does the same and also the NAS is authorizing a specific QoS profile, 423 not a pre-provisioned one. 425 End Diameter 426 Host NAS Server 427 | | | 428 | | | 429 | QoS Request | | 430 +----------------->| | 431 | | | 432 | |AA-Request | 433 | |Auth-Request-Type=AUTHORIZE_ONLY 434 | |NASREQ-Payload | 435 | |QoS-Resources(QoS-Desired) | 436 | +----------------------------->| 437 | | | 438 | | AA-Answer| 439 | | NASREQ-Payload(Success)| 440 | | QoS-Resources(QoS-Authorized)| 441 | |<-----------------------------+ 442 | Accept | | 443 |<-----------------+ | 444 | | | 445 | | | 446 | | | 448 Figure 13: Example of an Authorization-Only Message Flow 450 5.4. Diameter Server Initiated Re-authorization of QoS 452 Figure 14 shows a message exchange for a Diameter server initiated 453 QoS re-authorization procedure. The Diameter server sends the NAS a 454 RAR message requesting re-authorization for an existing session and 455 the NAS acknowledges it with a RAA message. The NAS is aware of its 456 existing QoS profile and information for the ongoing session that the 457 Diameter server requested for re-authorization. Thus, the NAS must 458 initiate re-authorization of the existing QoS profile. The re- 459 authorization procedure is the same as in Figure 13. 461 End Diameter 462 Host NAS Server 463 | | | 464 | | | 465 : : : 466 : <<>> : 467 : : : 468 | | | 469 | | RA-Request | 470 | |<-----------------------------+ 471 | | | 472 | |RA-Answer | 473 | |Result-Code=DIAMETER_SUCCESS | 474 | +----------------------------->| 475 | | | 476 | | | 477 | |AA-Request | 478 | |NASREQ-Payload | 479 | |Auth-Request-Type=AUTHORIZE_ONLY 480 | |QoS-Resources(QoS-Desired) | 481 | +----------------------------->| 482 | | | 483 | | AA-Answer| 484 | | Result-Code=DIAMETER_SUCCESS| 485 | | (authorization AVPs)| 486 | | QoS-Resources(QoS-Authorized)| 487 | |<-----------------------------+ 488 | | | 490 Figure 14: Example of a Server-initiated Re-Authorization Procedure 492 5.5. Diameter Credit Control with QoS Information 494 In this case the User is charged as soon as the Service Element (CC 495 client) receives the service request. In this case the client uses 496 the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP 497 that it sends to the Accounitng server. The server responds with a 498 "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP 499 Service Element 500 End User (CC Client) B CC Server 501 | | | | 502 |(1) Service Request | | | 503 |-------------------->| | | 504 | |(2) CCR (event, DIRECT_DEBITING,| 505 | | QoS-Resources[QoS-desired]) | 506 | |-------------------------------->| 507 | |(3) CCA (Granted-Units, QoS- | 508 | | Resources[QoS-Authorized]) | 509 | |<--------------------------------| 510 |(4) Service Delivery | | | 511 |<--------------------| | | 512 |(5) Begin service | | | 513 |<------------------------------------>| | 514 | | | | 515 . . . . 516 . . . . 518 Figure 15: Example for a One-Time Diameter Credit Control Charging 519 Event 521 6. Acknowledgments 523 We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, 524 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Avi Lior, 525 Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina 526 Tsou, Pete McCann, Georgios Karagiannis and Elwyn Davies for their 527 comments. 529 7. IANA Considerations 531 This specification requests IANA to assignment of new AVPs from the 532 AVP Code namespace defined in RFC 3588 [RFC3588]. Section 3 lists 533 the newly defined AVPs. 535 IANA is requested to allocate a registry for the QoS-Semantics. The 536 following values are allocated by this specification. 538 (0): QoS-Desired 539 (1): QoS-Available 540 (2): QoS-Reserved 541 (3): Minimum-QoS 542 (4): QoS-Authorized 544 A specification is required to add a new value to the registry. A 545 standards track document is required to depreciate, delete, or modify 546 existing values. 548 IANA is requested to allocate a registry for the QoS-Flow-State. The 549 following values are allocated by this specification. 551 Value | Name 552 ------+------------------------------------------------------------ 553 0 | QOS_FLOW_STATE_PENDING 555 A specification is required to add a new value to the registry. A 556 standards track document is required to depreciate, delete, or modify 557 existing values. 559 8. Security Considerations 561 This document describes the extension of Diameter for conveying 562 Quality of Service information. The security considerations of the 563 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 564 Use of the AVPs defined in this document MUST take into consideration 565 the security issues and requirements of the Diameter Base protocol. 567 9. References 569 9.1. Normative References 571 [I-D.ietf-dime-qos-parameters] 572 Korhonen, J. and H. Tschofenig, "Quality of Service 573 Parameters for Usage with the AAA Framework", 574 draft-ietf-dime-qos-parameters-01 (work in progress), 575 September 2007. 577 [I-D.ietf-radext-filter-rules] 578 Congdon, P., "RADIUS Attributes for Filtering and 579 Redirection", draft-ietf-radext-filter-rules-03 (work in 580 progress), July 2007. 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, March 1997. 585 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 586 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 588 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 589 "Diameter Network Access Server Application", RFC 4005, 590 August 2005. 592 9.2. Informative References 594 [I-D.ietf-dime-diameter-qos] 595 Zorn, G., "Diameter Quality of Service Application", 596 draft-ietf-dime-diameter-qos-01 (work in progress), 597 July 2007. 599 Authors' Addresses 601 Jouni Korhonen (editor) 602 TeliaSonera 603 Teollisuuskatu 13 604 Sonera FIN-00051 605 Finland 607 Email: jouni.korhonen@teliasonera.com 609 Hannes Tschofenig 610 Nokia Siemens Networks 611 Otto-Hahn-Ring 6 612 Munich, Bavaria 81739 613 Germany 615 Email: Hannes.Tschofenig@nsn.com 616 URI: http://www.tschofenig.com 618 Mayutan Arumaithurai 619 University of Goettingen 621 Email: mayutan.arumaithurai@gmail.com 623 Mark Jones 624 Bridgewater Systems 625 303 Terry Fox Drive 626 Ottawa, Ontario K2K 3J1 627 Canada 629 Email: mark.jones@bridgewatersystems.com 631 Full Copyright Statement 633 Copyright (C) The IETF Trust (2007). 635 This document is subject to the rights, licenses and restrictions 636 contained in BCP 78, and except as set forth therein, the authors 637 retain all their rights. 639 This document and the information contained herein are provided on an 640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 642 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 643 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 644 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 Intellectual Property 649 The IETF takes no position regarding the validity or scope of any 650 Intellectual Property Rights or other rights that might be claimed to 651 pertain to the implementation or use of the technology described in 652 this document or the extent to which any license under such rights 653 might or might not be available; nor does it represent that it has 654 made any independent effort to identify any such rights. Information 655 on the procedures with respect to rights in RFC documents can be 656 found in BCP 78 and BCP 79. 658 Copies of IPR disclosures made to the IETF Secretariat and any 659 assurances of licenses to be made available, or the result of an 660 attempt made to obtain a general license or permission for the use of 661 such proprietary rights by implementers or users of this 662 specification can be obtained from the IETF on-line IPR repository at 663 http://www.ietf.org/ipr. 665 The IETF invites any interested party to bring to its attention any 666 copyrights, patents or patent applications, or other proprietary 667 rights that may cover technology that may be required to implement 668 this standard. Please address the information to the IETF at 669 ietf-ipr@ietf.org. 671 Acknowledgment 673 Funding for the RFC Editor function is provided by the IETF 674 Administrative Support Activity (IASA).