idnits 2.17.1 draft-ietf-dime-qos-attributes-05.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 608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 632. 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 (February 22, 2008) is 5909 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 328, but not defined == Missing Reference: 'QoS-desired' is mentioned on line 478, but not defined == Missing Reference: 'QoS-Authorized' is mentioned on line 481, 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-04 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: August 25, 2008 M. Arumaithurai 7 University of Goettingen 8 M. Jones 9 Bridgewater Systems 10 February 22, 2008 12 Quality of Service Attributes for Diameter 13 draft-ietf-dime-qos-attributes-05.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 August 25, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 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 and future Diameter applications where permitted by the 51 command ABNF. 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-Semantics . . . . . . . . . . . . . . . . . . . . . . 5 63 3.6. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 5 64 3.7. QoS-Rule-Precedence AVP . . . . . . . . . . . . . . . . . 5 65 3.8. QoS-Flow-Direction AVP . . . . . . . . . . . . . . . . . . 6 66 4. Semantics of QoS Parameters . . . . . . . . . . . . . . . . . 6 67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. Diameter EAP with QoS Information . . . . . . . . . . . . 7 69 5.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 8 70 5.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 9 71 5.4. Diameter Server Initiated Re-authorization of QoS . . . . 10 72 5.5. Diameter Credit Control with QoS Information . . . . . . . 11 73 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 80 Intellectual Property and Copyright Statements . . . . . . . . . . 15 82 1. Introduction 84 This document defines a number of Diameter Quality of Service (QoS) 85 related AVPs that can be used in existing and future Diameter 86 applications where permitted by the command ABNF. The Extended-QoS- 87 Filter-Rule AVP thereby replaces the QoSFilterRule, defined in RFC 88 3588 [RFC3588], and the QoS-Filter-Rule, defined in RFC 4005 89 [RFC4005]. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 3. Diameter QoS Defined AVPs 99 The following table lists the Diameter AVPs used by this document, 100 their AVP code values, types and possible flag values. 102 +------------------+ 103 | AVP Flag Rules | 104 +-------------------------------------------------|----+---+----+----+ 105 | AVP Section |MUST|MAY|SHLD|MUST| 106 | Attribute Name Code Defined Data Type | | | NOT| NOT| 107 +-------------------------------------------------+----+---+----+----+ 108 |QoS-Capability TBD 3.1 Grouped | |M,P| | V | 109 |QoS-Profile-Template TBD 3.2 Unsigned64 | |M,P| | V | 110 |QoS-Resources TBD 3.3 Grouped | |M,P| | V | 111 |Extended-QoS-Filter-Rule TBD 3.4 Grouped | |M,P| | V | 112 |QoS-Semantics TBD 3.5 Enumerated | |M,P| | V | 113 |QoS-Parameters TBD 3.6 OctetString| |M,P| | V | 114 |QoS-Rule-Precedence TBD 3.7 Unsigned32 | |M,P| | V | 115 |QoS-Flow-Direction TBD 3.9 Enumerated | |M,P| | V | 116 +-------------------------------------------------+----+---+----+----+ 118 3.1. QoS-Capability AVP 120 The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains 121 a list of supported Quality of Service profile templates (and 122 therefore the support of the respective parameter AVPs). 124 QoS-Capability ::= < AVP Header: XXX > 125 1* { QoS-Profile-Template } 126 * [ AVP ] 128 3.2. QoS-Profile-Template AVP 130 The QoS-Profile-Template AVP (AVP Code TBD) is of type Unsigned64 and 131 contains a vendor and a specifier field. The 64-bit value in the 132 QoS-Profile-Template AVP is structured as shown below. 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Vendor | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Specifier | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Vendor Field: 144 32 bits of IANA SMI Network Management Private Enterprise Code. 145 The Vendor-ID 0x00000000 is reserved for IANA registered QoS 146 profiles. 148 Specifier Field: 150 32-bit unsigned integer, representing the defined profile value. 152 An initial QoS profile template is defined with vendor field set to 153 0x00000000 and the specifier field set to 0. The initial QoS profile 154 template is described in [I-D.ietf-dime-qos-parameters]. The 155 registry for the QoS profile templates is created with the same 156 document. 158 3.3. QoS-Resources AVP 160 The QoS-Resources AVP (AVP Code TBD) is of type Grouped and includes 161 a description of the Quality of Service resources for policing 162 traffic flows. 164 QoS-Resources ::= < AVP Header: XXX > 165 * [ Extended-QoS-Filter-Rule ] 166 [ QoS-Flow-State ] 167 * [ AVP ] 169 3.4. Extended-QoS-Filter-Rule AVP 171 The Extended-QoS-Filter-Rule AVP (AVP Code TBD) is of type Grouped 172 and defines one or more traffic flows together with a set of QoS 173 parameters that should be applied to the flow(s) by the Resource 174 Management Function. This AVP re-uses the RADIUS NAS-Traffic-Rule 175 AVP [I-D.ietf-radext-filter-rules] to describe traffic flows. At 176 least either one of the NAS-Traffic-Rule or the QoS-Flow-Direction 177 AVPs SHOULD be included. 179 Extended-QoS-Filter-Rule ::= < AVP Header: XXX > 180 { QoS-Semantics } 181 { QoS-Profile-Template } 182 [ QoS-Parameters ] 183 [ QoS-Rule-Precedence ] 184 [ NAS-Traffic-Rule ] 185 [ QoS-Flow-Direction ] 186 * [ AVP ] 188 3.5. QoS-Semantics 190 The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and 191 provides the semantics for the QoS-Profile-Template and QoS- 192 Parameters AVPs in the Extended-QoS-Filter-Rule AVP. 194 This document defines the following values: 196 (0): QoS-Desired 197 (1): QoS-Available 198 (2): QoS-Reserved 199 (3): Minimum-QoS 200 (4): QoS-Authorized 202 3.6. QoS-Parameters AVP 204 The QoS-Parameters AVP (AVP Code TBD) is of type OctetString and 205 contains Quality of Service parameters. These parameters are defined 206 in a separate document, see [I-D.ietf-dime-qos-parameters]. 208 3.7. QoS-Rule-Precedence AVP 210 The QoS-Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and 211 specifies the execution order of the rules expressed in the QoS- 212 Resources AVP. Rules with equal precedence MAY be executed in 213 parallel if supported by the Resource Management Function. If the 214 QoS-Rule-Precedence AVP is absent from the Extended-QoS-Filter-Rule 215 AVP, the rules SHOULD be executed in the order in which they appear 216 in the QoS-Resources AVP. 218 3.8. QoS-Flow-Direction AVP 220 The QoS-Flow-Direction AVP (AVP Code TBD) is of type Enumerated. It 221 gives an indication of the direction the provided QoS information 222 should be applied to. The QoS information can be applied to downlink 223 flows or to uplink flows. The QoS-Flow-Direction AVP may be used in 224 conjunction with the NAS-Traffic-Rule AVP. In a case conflicting 225 definitions between the QoS-Flow-Direction and the NAS-Traffic-Rule, 226 the QoS-Flow-Direction has precedence meaning the filter rules are 227 applied only to the flows going to the direction indicated by the 228 QoS-Flow-Direction AVP. In the absence of the QoS-Flow-Direction the 229 default treatment is to both directions. 231 Value | Name and Semantic 232 ------+------------------------------------------------------------ 233 0 | QOS_FLOW_DIRECTION_BOTH - The QoS information in applied to 234 | both downlink and uplink flows. This is also the default. 235 1 | QOS_FLOW_DIRECTION_DL - The QoS information in applied to 236 | downlink flows only. 237 2 | QOS_FLOW_DIRECTION_UL - The QoS information in applied to 238 | uplink flows only. 240 4. Semantics of QoS Parameters 242 The QoS parameters carried in the QoS-Resources AVP may appear in 243 different messages. The semantic of the QoS parameters depend on the 244 information provided in the QoS-Semantics AVP which currently defines 245 5 values, namely QoS-Desired (0), QoS-Available (1), QoS-Reserved 246 (2), Minimum-QoS (3), and QoS-Authorized (4). 248 The semantics of the different values are as follows: 250 Object Type Direction Semantic 251 ---------------------------------------------------------------------- 252 QoS-Desired C->S Please authorize the indicated QoS 253 QoS-Desired C<-S NA 254 QoS-Available C->S Admission Control at router indicates 255 that this QoS is available. (note 1) 256 QoS-Available C<-S Indicated QoS is available. (note 2) 257 QoS-Reserved C->S Used for reporting during accounting. 258 QoS-Reserved C<-S NA 259 Minimum-QoS C->S Indicates that the client is not interested 260 interested in authorizing QoS that is 261 lower than Min. QoS 262 Minimum-QoS C<-S The client must not provide QoS guarantees 263 lower than Min. QoS 264 QoS-Authorized C->S NA 265 QoS-Authorized C<-S Indicated QoS authorized 267 Legend: 269 C: Diameter client 270 S: Diameter server 271 NA: Not applicable to this document; 272 no semantic defined in this specification 274 Notes: 276 (1) QoS-Available is only useful in relationship with QoS-Desired 277 (and optionally with Minimum-QoS). 278 (2) QoS-Available is only useful when the AAA server performs 279 admission control and knows about the resources in the network. 281 5. Examples 283 This section shows a number of signaling flows where QoS negotiation 284 and authorization is part of the conventional NASREQ, EAP or Credit 285 Control applications message exchanges. The signalling flows for the 286 Diameter QoS Application are described in 287 [I-D.ietf-dime-diameter-qos]. 289 5.1. Diameter EAP with QoS Information 291 Figure 9 shows a simple signaling flow where a NAS (Diameter Client) 292 announces its QoS awareness and capabilities included into the DER 293 message and as part of the access authentication procedure. Upon 294 completion of the EAP exchange, the Diameter Server provides a pre- 295 provisioned QoS profile with the QoS-Semantics in the Extended-QoS- 296 Filter-Rule AVP set to "QoS-Authorized", to the NAS in the final DEA 297 message. 299 End Diameter Diameter 300 Host Client server 301 | | | 302 | (initiate EAP) | | 303 |<------------------------------>| | 304 | | Diameter-EAP-Request | 305 | | EAP-Payload(EAP Start) | 306 | | QoS-Capability | 307 | |------------------------------->| 308 | | | 309 | | Diameter-EAP-Answer | 310 | Result-Code=DIAMETER_MULTI_ROUND_AUTH | 311 | | EAP-Payload(EAP Request #1) | 312 | |<-------------------------------| 313 | EAP Request(Identity) | | 314 |<-------------------------------| | 315 : : : 316 : <<>> : 317 : : : 318 | | | 319 | EAP Response #N | | 320 |------------------------------->| | 321 | | Diameter-EAP-Request | 322 | | EAP-Payload(EAP Response #N) | 323 | |------------------------------->| 324 | | | 325 | | Diameter-EAP-Answer | 326 | | Result-Code=DIAMETER_SUCCESS | 327 | | EAP-Payload(EAP Success) | 328 | | [EAP-Master-Session-Key] | 329 | | (authorization AVPs) | 330 | | QoS-Resources(QoS-Authorized) | 331 | |<-------------------------------| 332 | | | 333 | EAP Success | | 334 |<-------------------------------| | 335 | | | 337 Figure 9: Example of a Diameter EAP enhanced with QoS Information 339 5.2. Diameter NASREQ with QoS Information 341 Figure 10 shows a similar pre-provisioned QoS signaling as in 342 Figure 9 but using the NASREQ application instead of EAP application. 344 End Diameter 345 Host NAS Server 346 | | | 347 | Start Network | | 348 | Attachment | | 349 |<---------------->| | 350 | | | 351 | |AA-Request | 352 | |NASREQ-Payload | 353 | |QoS-Capability | 354 | +----------------------------->| 355 | | | 356 | | AA-Answer| 357 | Result-Code=DIAMETER_MULTI_ROUND_AUTH| 358 | NASREQ-Payload(NASREQ Request #1)| 359 | |<-----------------------------+ 360 | | | 361 | Request | | 362 |<-----------------+ | 363 | | | 364 : : : 365 : <<>> : 366 : : : 367 | Response #N | | 368 +----------------->| | 369 | | | 370 | |AA-Request | 371 | |NASREQ-Payload ( Response #N )| 372 | +----------------------------->| 373 | | | 374 | | AA-Answer| 375 | | Result-Code=DIAMETER_SUCCESS| 376 | | (authorization AVPs)| 377 | |QoS-Resources(QoS-Authorized) | 378 | |<-----------------------------+ 379 | | | 380 | Success | | 381 |<-----------------+ | 382 | | | 384 Figure 10: Example of a Diameter NASREQ enhanced with QoS Information 386 5.3. QoS Authorization 388 Figure 11 shows an example of authorization only QoS signaling as 389 part of the NASREQ message exchange. The NAS provides the Diameter 390 server with the "QoS-Desired" QoS-Semantics AVP included in the QoS- 391 Resources AVP. The Diameter server then either authorizes the 392 indicated QoS or rejects the request and informs the NAS about the 393 result. In this scenario the NAS does not need to include the QoS- 394 Capability AVP in the AAR message as the QoS-Resources AVP implicitly 395 does the same and also the NAS is authorizing a specific QoS profile, 396 not a pre-provisioned one. 398 End Diameter 399 Host NAS Server 400 | | | 401 | | | 402 | QoS Request | | 403 +----------------->| | 404 | | | 405 | |AA-Request | 406 | |Auth-Request-Type=AUTHORIZE_ONLY 407 | |NASREQ-Payload | 408 | |QoS-Resources(QoS-Desired) | 409 | +----------------------------->| 410 | | | 411 | | AA-Answer| 412 | | NASREQ-Payload(Success)| 413 | | QoS-Resources(QoS-Authorized)| 414 | |<-----------------------------+ 415 | Accept | | 416 |<-----------------+ | 417 | | | 418 | | | 419 | | | 421 Figure 11: Example of an Authorization-Only Message Flow 423 5.4. Diameter Server Initiated Re-authorization of QoS 425 Figure 12 shows a message exchange for a Diameter server initiated 426 QoS re-authorization procedure. The Diameter server sends the NAS a 427 RAR message requesting re-authorization for an existing session and 428 the NAS acknowledges it with a RAA message. The NAS is aware of its 429 existing QoS profile and information for the ongoing session that the 430 Diameter server requested for re-authorization. Thus, the NAS must 431 initiate re-authorization of the existing QoS profile. The re- 432 authorization procedure is the same as in Figure 11. 434 End Diameter 435 Host NAS Server 436 | | | 437 | | | 438 : : : 439 : <<>> : 440 : : : 441 | | | 442 | | RA-Request | 443 | |<-----------------------------+ 444 | | | 445 | |RA-Answer | 446 | |Result-Code=DIAMETER_SUCCESS | 447 | +----------------------------->| 448 | | | 449 | | | 450 | |AA-Request | 451 | |NASREQ-Payload | 452 | |Auth-Request-Type=AUTHORIZE_ONLY 453 | |QoS-Resources(QoS-Desired) | 454 | +----------------------------->| 455 | | | 456 | | AA-Answer| 457 | | Result-Code=DIAMETER_SUCCESS| 458 | | (authorization AVPs)| 459 | | QoS-Resources(QoS-Authorized)| 460 | |<-----------------------------+ 461 | | | 463 Figure 12: Example of a Server-initiated Re-Authorization Procedure 465 5.5. Diameter Credit Control with QoS Information 467 In this case the User is charged as soon as the Service Element (CC 468 client) receives the service request. In this case the client uses 469 the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP 470 that it sends to the Accounitng server. The server responds with a 471 "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP 472 Service Element 473 End User (CC Client) B CC Server 474 | | | | 475 |(1) Service Request | | | 476 |-------------------->| | | 477 | |(2) CCR (event, DIRECT_DEBITING,| 478 | | QoS-Resources[QoS-desired]) | 479 | |-------------------------------->| 480 | |(3) CCA (Granted-Units, QoS- | 481 | | Resources[QoS-Authorized]) | 482 | |<--------------------------------| 483 |(4) Service Delivery | | | 484 |<--------------------| | | 485 |(5) Begin service | | | 486 |<------------------------------------>| | 487 | | | | 488 . . . . 489 . . . . 491 Figure 13: Example for a One-Time Diameter Credit Control Charging 492 Event 494 6. Acknowledgments 496 We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, 497 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Avi Lior, 498 Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina 499 Tsou, Pete McCann, Georgios Karagiannis and Elwyn Davies for their 500 comments. 502 7. IANA Considerations 504 This specification requests IANA to assignment of new AVPs from the 505 AVP Code namespace defined in RFC 3588 [RFC3588]. Section 3 lists 506 the newly defined AVPs. 508 IANA is requested to allocate a registry for the QoS-Semantics. The 509 following values are allocated by this specification. 511 (0): QoS-Desired 512 (1): QoS-Available 513 (2): QoS-Reserved 514 (3): Minimum-QoS 515 (4): QoS-Authorized 517 A specification is required to add a new value to the registry. A 518 standards track document is required to depreciate, delete, or modify 519 existing values. 521 8. Security Considerations 523 This document describes the extension of Diameter for conveying 524 Quality of Service information. The security considerations of the 525 Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. 526 Use of the AVPs defined in this document MUST take into consideration 527 the security issues and requirements of the Diameter Base protocol. 529 9. References 531 9.1. Normative References 533 [I-D.ietf-dime-qos-parameters] 534 Korhonen, J. and H. Tschofenig, "Quality of Service 535 Parameters for Usage with the AAA Framework", 536 draft-ietf-dime-qos-parameters-01 (work in progress), 537 September 2007. 539 [I-D.ietf-radext-filter-rules] 540 Congdon, P., "RADIUS Attributes for Filtering and 541 Redirection", draft-ietf-radext-filter-rules-03 (work in 542 progress), July 2007. 544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 548 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 550 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 551 "Diameter Network Access Server Application", RFC 4005, 552 August 2005. 554 9.2. Informative References 556 [I-D.ietf-dime-diameter-qos] 557 Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 558 and G. Zorn, "Diameter Quality of Service Application", 559 draft-ietf-dime-diameter-qos-04 (work in progress), 560 January 2008. 562 Authors' Addresses 564 Jouni Korhonen (editor) 565 TeliaSonera 566 Teollisuuskatu 13 567 Sonera FIN-00051 568 Finland 570 Email: jouni.korhonen@teliasonera.com 572 Hannes Tschofenig 573 Nokia Siemens Networks 574 Otto-Hahn-Ring 6 575 Munich, Bavaria 81739 576 Germany 578 Email: Hannes.Tschofenig@nsn.com 579 URI: http://www.tschofenig.com 581 Mayutan Arumaithurai 582 University of Goettingen 584 Email: mayutan.arumaithurai@gmail.com 586 Mark Jones 587 Bridgewater Systems 588 303 Terry Fox Drive 589 Ottawa, Ontario K2K 3J1 590 Canada 592 Email: mark.jones@bridgewatersystems.com 594 Full Copyright Statement 596 Copyright (C) The IETF Trust (2008). 598 This document is subject to the rights, licenses and restrictions 599 contained in BCP 78, and except as set forth therein, the authors 600 retain all their rights. 602 This document and the information contained herein are provided on an 603 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 604 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 605 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 606 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 607 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 610 Intellectual Property 612 The IETF takes no position regarding the validity or scope of any 613 Intellectual Property Rights or other rights that might be claimed to 614 pertain to the implementation or use of the technology described in 615 this document or the extent to which any license under such rights 616 might or might not be available; nor does it represent that it has 617 made any independent effort to identify any such rights. Information 618 on the procedures with respect to rights in RFC documents can be 619 found in BCP 78 and BCP 79. 621 Copies of IPR disclosures made to the IETF Secretariat and any 622 assurances of licenses to be made available, or the result of an 623 attempt made to obtain a general license or permission for the use of 624 such proprietary rights by implementers or users of this 625 specification can be obtained from the IETF on-line IPR repository at 626 http://www.ietf.org/ipr. 628 The IETF invites any interested party to bring to its attention any 629 copyrights, patents or patent applications, or other proprietary 630 rights that may cover technology that may be required to implement 631 this standard. Please address the information to the IETF at 632 ietf-ipr@ietf.org. 634 Acknowledgment 636 Funding for the RFC Editor function is provided by the IETF 637 Administrative Support Activity (IASA).