idnits 2.17.1 draft-ietf-dime-diameter-qos-02.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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1655. 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 19, 2007) is 5974 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: 'TBD' is mentioned on line 846, but not defined == Unused Reference: 'RFC4005' is defined on line 1515, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-ntlp' is defined on line 1525, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-qos-nslp' is defined on line 1530, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 1534, but no explicit reference was found in the text == Unused Reference: 'RFC2749' is defined on line 1540, but no explicit reference was found in the text == Unused Reference: 'RFC2753' is defined on line 1544, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 1548, but no explicit reference was found in the text == Unused Reference: 'RFC3313' is defined on line 1552, but no explicit reference was found in the text == Unused Reference: 'RFC3520' is defined on line 1556, but no explicit reference was found in the text == Unused Reference: 'RFC3521' is defined on line 1560, but no explicit reference was found in the text == Unused Reference: 'RFC4027' is defined on line 1564, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 1567, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-03 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-14 == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-15 -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn, Ed. 3 Internet-Draft 4 Intended status: Standards Track P. McCann 5 Expires: May 22, 2008 Motorola Labs 6 H. Tschofenig 7 Nokia Siemens Networks 8 T. Tsou 9 Huawei 10 A. Doria 11 Lulea University of Technology 12 D. Sun 13 Bell Labs/Alcatel-Lucent 14 November 19, 2007 16 Protocol for Diameter Quality of Service Application 17 draft-ietf-dime-diameter-qos-02.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on May 22, 2008. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). 48 Abstract 50 This document describes the messages and procedures for the Diameter 51 QoS application. The QoS application allows network elements to 52 interact with Diameter servers when allocating QoS resources in the 53 network. In particular, two modes of operation - Pull and Push are 54 defined. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Diameter QoS Authorization Session Establishment and 61 Management . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Parties involved . . . . . . . . . . . . . . . . . . . . . 6 63 3.2. Diameter QoS Authorization Session Establishment . . . . . 6 64 3.2.1. QoS authorization session establishment for pull 65 mode . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2.2. QoS authorization session establishment for push 67 mode . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.2.3. Discovery and selection of peer Diameter QoS 69 application node . . . . . . . . . . . . . . . . . . . 13 70 3.3. QoS authorization session re-authorization . . . . . . . . 13 71 3.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 14 72 3.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 16 73 3.4. Session Termination . . . . . . . . . . . . . . . . . . . 18 74 3.4.1. Client-Side Initiated Session Termination . . . . . . 18 75 3.4.2. Server-Side Initiated Session Termination . . . . . . 19 76 4. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 5. Diameter QoS Authorization Application Messages . . . . . . . 22 78 5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 23 79 5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 23 80 5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 24 81 5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 25 82 5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 25 83 5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 26 84 5.7. Accounting Request (ACR) . . . . . . . . . . . . . . . . . 26 85 5.8. Accounting Answer (ACA) . . . . . . . . . . . . . . . . . 27 86 6. Diameter QoS Authorization Application AVPs . . . . . . . . . 28 87 6.1. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 28 88 6.2. Credit Control Application AVPs . . . . . . . . . . . . . 28 89 6.3. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 29 90 6.4. Diameter QoS Application Defined AVPs . . . . . . . . . . 29 91 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 92 7.1. Example call flow for pull mode . . . . . . . . . . . . . 31 93 7.2. Example call flow for push mode . . . . . . . . . . . . . 33 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 97 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 40 98 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 100 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 101 13.2. Informative References . . . . . . . . . . . . . . . . . . 42 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 103 Intellectual Property and Copyright Statements . . . . . . . . . . 46 105 1. Introduction 107 This document describes the messages and procedures for the Diameter 108 QoS Application. The QoS Application allows network elements to 109 interact with Diameter servers when allocating QoS resources in the 110 network. 112 In particular, two modes of operation are defined. In the first, 113 called "Pull Mode", the network element queries the Diameter 114 infrastructure for authorization based on some trigger (such as a QoS 115 signaling protocol) that arrives along the data path to be used for 116 the session. In the second, called "Push Mode", a Diameter server 117 pro-actively sends a command to the network element(s) to install QoS 118 authorization state. This could be triggered, for instance, by off- 119 path signaling such as SIP-based call control. 121 A set of command codes pertinent to this QoS application are 122 specified that allows a single Diameter application to support both 123 Pull and Push modes based on the requirements of network 124 technologies, deployment scenarios and end-host's capabilities. In 125 conjunction with parameters defined in other Diameter QoS documents, 126 this document depicts basic call flow procedures to establish, modify 127 and terminate a Diameter QoS application session. 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 In addition to the terms defined in other relevant Diameter QoS 136 documents (e.g., diameter-qos-framework), the following terms are 137 used in this document: 139 Diameter QoS Application Server 141 A Diameter QoS application server is a logical Diameter node that 142 supports the protocol interaction for QoS authorization. The 143 Diameter QoS server resides in the authorizing entity and is able 144 to respond to a Diameter session received from a Diameter QoS 145 client, or initiate a Diameter session to a Diameter QoS client 146 triggered by application signaling or local events. 148 Diameter QoS Application Client 150 A Diameter QoS application client is a logical Diameter node that 151 supports the protocol interaction for QoS enforcement. The 152 Diameter QoS client resides in the network element and is able to 153 initiate a Diameter session triggered by a QoS signaling or other 154 events, or respond to a Diameter session initiated by a Diameter 155 QoS server. 157 Resource Requesting Entity 159 A resource requesting entity is a logical entity that supports the 160 protocol interaction for QoS resources. The resource requesting 161 entity resides in the end-host and is able to communicate with 162 peer logicial entities in Authorizing Entity or Network element to 163 trigger the QoS authorization process. 165 3. Diameter QoS Authorization Session Establishment and Management 167 3.1. Parties involved 169 Authorization models supported by this application include three 170 parties: 171 o Resource requesting entity 172 o Network Elements (Diameter QoS application (DQA) client) 173 o Authorizing Entity (Diameter QoS application (DQA) server) 175 Note that the QoS resource requesting entity is only indirectly 176 involved in the message exchange. This entity provides the trigger 177 to initiate the Diameter QoS protocol interaction by transmitting QoS 178 signaling messages. The Diameter QoS application is only executed 179 between the Network Element (i.e., DQA client) and the Authorizing 180 Entity (i.e., DQA server). 182 The QoS resource requesting entity may communicate with the 183 Authorizing Entity using application layer signaling for negotiation 184 of service parameters. As part of this application layer protocol 185 interaction, for example using SIP, authentication and authorization 186 might take place. This message exchange is, however, outside the 187 scope of this document. The protocol communication between the QoS 188 resource requesting entity and the QoS Network Element might be 189 accomplished using the NSIS protocol suite, RSVP or a link layer 190 signaling protocol. A description of these protocols is also outside 191 the scope of this document and a tight coupling with these protocols 192 is not desirable since this applications aims to be generic. 194 3.2. Diameter QoS Authorization Session Establishment 196 The Pull and Push modes use a different set of command codes for 197 session establishment. For other operations, such as session 198 modification and termination, they use the same set of command codes. 200 The Pull mode or Push mode operation is invoked based on the trigger 201 of QoS Authorization session. When a QAR with a new session ID is 202 received, the Authorizing Entity operates in the pull mode; when 203 other triggers are received, the Authorizing Entity operates in the 204 push mode. Similarly, when a QIR with new session ID is received, 205 the Network Element operates in the push mode; when other triggers 206 are recevied, the Network Element operation in the pull mode. 208 3.2.1. QoS authorization session establishment for pull mode 210 A request for a QoS reservation or local events received by a Network 211 Element can trigger the initiation of a Diameter QoS authorization 212 session. The Network Element generates a QoS-Authorization-Request 213 (QAR) message in which it maps required objects from the QoS 214 signaling message to Diameter payload objects. 216 Figure 2 shows the protocol interaction between a resource requesting 217 entity, a Network Element and the Authorizing Entity. 219 The Authorizing Entity's identity, information about the application 220 session and/or identity and credentials of the QoS resource 221 requesting entity, requested QoS parameters, signaling session 222 identifier and/or QoS enabled data flows identifiers MAY be 223 encapsulated into respective Diameter AVPs and included into the 224 Diameter message sent to the Authorizing Entity. The QAR is sent to 225 a Diameter server that can either be the home server of the QoS 226 requesting entity or an application server. 228 +----------------------------------+-------------------------------+ 229 | QoS specific Input Data | Diameter QoS AVPs | 230 +----------------------------------+-------------------------------+ 231 | Authorizing entity ID (e.g., | Destination-Host | 232 | taken from authorization token | Destination-Realm | 233 | or derived based on Network | | 234 | Access ID (NAI) [RFC2486] | | 235 | of the QoS requesting entity) | | 236 +----------------------------------+-------------------------------+ 237 | Authorization Token | QoS-Authz-Data | 238 | Credentials of | User-Name | 239 | the QoS requesting entity | | 240 +----------------------------------+-------------------------------+ 241 | QoS parameters | QoS-Resources | 242 +----------------------------------+-------------------------------+ 244 Authorization processing starts at the Diameter QoS server when it 245 receives the QAR. Based on the information in the QoS- 246 Authentication-Data, User-Name and QoS-Resources AVPs the server 247 determines the authorized QoS resources and flow state (enabled/ 248 disabled) from locally available information (e.g., policy 249 information that may be previously established as part of an 250 application layer signaling exchange, or the user's subscription 251 profile). The QoS-Resources AVP is defined in 252 [I-D.ietf-dime-qos-attributes]. The authorization decision is then 253 reflected in the response returned to the Diameter client with the 254 QoS-Authorization-Answer message (QAA). 256 Authorizing 257 End-Host Network Element Entity 258 requesting QoS ( Diameter ( Diameter 259 QoS Client) QoS Server) 260 | | | 261 +---QoS-Reserve---->| | 262 | +- - - - - QAR - - - - - >| 263 | |(QoS-Resources,Cost, | 264 | | QoS-Auth-Data,User-ID)| 265 | | +--------+--------------+ 266 | | | Authorize request | 267 | | | Keep session data | 268 | | |/Authz-time,Session-Id/| 269 | | +--------+--------------+ 270 | |< - - - - QAA - - - - - -+ 271 | |(Result-Code,CC-Time,Cost| 272 | |QoS-Resources,Authz-time)| 273 | +-------+---------+ 274 | |Install QoS state| 275 | | + | 276 | | Authz. session | 277 | | /Authz-time, | QoS Responder 278 | | CC-Time,Cost/ | Node 279 | +-------+---------+ | 280 | +----------QoS-Reserve---....--->| 281 | | | 282 | |<---------QoS-Response--....----| 283 |<--QoS-Response----+ | 284 | | | 285 |=====================Data Flow==============....===>| 286 | | 287 | +- - - - - ACR - - - - - >| 288 | |(START,QoS-Resources,Cost| 289 | |CC-Time,Acc-Multisess-id)| 290 | | +--------+--------------+ 291 | | | Report for successful | 292 | | | QoS reservation | 293 | | |Update of reserved QoS | 294 | | | resources | 295 | | +--------+--------------+ 296 | |< - - - - ACA - - - - - -+ 297 | | | 299 Figure 2: Initial QoS Request Authorization for pull 301 The Authorizing Entity keeps authorization session state and SHOULD 302 save additional information for management of the session (e.g., Acc- 303 Multi-Session-Id, Signaling-Session-Id, authentication data) as part 304 of the session state information. A Signaling-session-Id (if 305 present) SHOULD be used together with the generated Acc-Multi- 306 Session-Id AVP (see Section 6.3) for binding the authorization and 307 the accounting session information in case of end host mobility 308 (i.e., to correlate the Diameter sessions that are initiated for the 309 same signaling session from different QoS NE). 311 The final result of the authorization request is provided in the 312 Result-Code AVP of the QAA message sent by the Authorizing Entity. 313 In case of successful authorization (i.e., Result-Code = 314 DIAMETER_LIMITED_SUCCESS, (see Section 6.1)), information about the 315 authorized QoS resources and the status of the authorized flow 316 (enabled/disabled) is provided in the QoS-Resources AVP of the QAA 317 message. The QoS information provided via the QAA is installed by 318 the QoS Traffic Control function of the Network Element. The value 319 DIAMETER_LIMITED_SUCCESS indicates that the Authorizing entity 320 expects confirmation via an accounting message for successful QoS 321 resource reservation and for final reserved QoS resources (see 322 below). 324 One important piece of information returned from the Authorizing 325 Entity is the authorization lifetime (carried inside the QAA). The 326 authorization lifetime allows the Network Element to determine how 327 long the authorization decision is valid for this particular QoS 328 reservation. A number of factors may influence the authorized 329 session duration, such as the user's subscription plan or currently 330 available credits at the user's account (see Section 4). The 331 authorization duration is time-based as specified in [RFC3588]. For 332 an extension of the authorization period, a new QoS-Authorization- 333 Request/Answer message exchange SHOULD be initiated. Further aspects 334 of QoS authorization session maintenance is discussed in Section 3.3, 335 Section 3.4 and Section 4. 337 The indication of a successful QoS reservation and activation of the 338 data flow is provided by the transmission of an Accounting Request 339 (ACR) message, which reports the parameters of the established QoS 340 state: reserved resources, duration of the reservation, 341 identification of the QoS enabled flow/QoS signaling session and 342 accounting parameters. The Diameter QoS server acknowledges the 343 reserved QoS resources with the Accounting Answer (ACA) message where 344 the Result-Code is set to 'DIAMETER_SUCCESS'. Note that the reserved 345 QoS resources reported in the ACR message MAY be different than those 346 initially authorized with the QAA message, due to the QoS signaling 347 specific behavior (e.g., receiver-initiated reservations with One- 348 Path-With-Advertisements) or specific process of QoS negotiation 349 along the data path. 351 3.2.2. QoS authorization session establishment for push mode 353 The Diameter QoS server in the Authorizing Entity initiates a 354 Diameter QoS authorization session upon the request for QoS 355 reservation triggered by application layer signaling or by local 356 events, and generates a QoS-Install-Request (QIR) message to Diameter 357 QoS client in the NE in which it maps required objects to Diameter 358 payload objects. 360 Figure 4 shows the protocol interaction between the Authorizing 361 Entity, a Network Element and a resource requesting entity. 363 The Network Element's identity, information about the application 364 session and/or identity and credentials of the QoS resource 365 requesting entity, requested QoS parameters, signaling session 366 identifier and/or QoS enabled data flows identifiers MAY be 367 encapsulated into respective Diameter AVPs and included into the 368 Diameter message sent from a Diameter QoS server in the Authorizing 369 Entity to a Diameter QoS client in the NE. This requires that the 370 Authorizing Entity has knowledge of specific information for 371 allocating and identifying the Network Element that should be 372 contacted and the data flow for which the QoS reservation should be 373 established. This information can be statically configured or 374 dynamically discovered, see section 3.2.3 for details. 376 +----------------------------------+-------------------------------+ 377 | QoS specific Input Data | Diameter QoS AVPs | 378 +----------------------------------+-------------------------------+ 379 | Network Element ID (e.g., from | Destination-Host | 380 | static configuration | Destination-Realm | 381 | or dynamically discovered, see | | 382 | section 3.2.3 for details) | | 383 +----------------------------------+-------------------------------+ 384 | Authorization Token | QoS-Authz-Data | 385 | Credentials of | User-Name | 386 | the QoS requesting entity | | 387 +----------------------------------+-------------------------------+ 388 | QoS parameters | QoS-Resources | 389 +----------------------------------+-------------------------------+ 391 Authorization processing starts at the Diameter QoS server when it 392 receives the request from a resource requesting entity through 393 application server (e.g. SIP Invite) or the trigger by local events 394 (e.g. pre-configured timer). Based on the received information the 395 server determines the authorized QoS resources and flow state 396 (enabled/disabled) from locally available information (e.g., policy 397 information that may be previously established as part of an 398 application layer signaling exchange, or the user's subscription 399 profile). The authorization decision is then reflected in the QoS- 400 Install-Request message (QIR) to the Diameter QoS client. 402 Authorizing 403 End-Host Network Element Entity 404 requesting QoS ( Diameter ( Diameter 405 QoS Client) QoS Server) 406 | | | 407 | | |<-- Trigger -- 408 | | +--------+--------------+ 409 | | | Authorize request | 410 | | | Keep session data | 411 | | |/Authz-time,Session-Id/| 412 | | +--------+--------------+ 413 | | | 414 | |<-- - -- - QIR - - - - - -+ 415 | |(Initial Request,Decision | 416 | |(QoS-Resources,Authz-time)| 417 | +-------+---------+ 418 | |Install QoS state| 419 | | + | 420 | | Authz. session | 421 | | /Authz-time, | 422 | | CC-Time,Cost/ | 423 | +-------+---------+ 424 | + - - - - QIA - - - - - ->| 425 | | (Result-Code, | 426 | | QoS-Resources) | 427 | | +--------+--------------+ 428 | | | Report for successful | 429 | | | QoS reservation | 430 | | |Update of reserved QoS | 431 | | | resources | 432 | | +--------+--------------+ 433 | | QoS Responder 434 | | Node 435 | | | 436 |=====================Data Flow==============....===>| 437 | | 438 | +- - - - - ACR - - - - - >| 439 | |(START,QoS-Resources,Cost| 440 | |CC-Time,Acc-Multisess-id)| 441 | |< - - - - ACA - - - - - -+ 442 | | | 444 Figure 4: Initial QoS Request Authorization for push 446 The Authorizing Entity keeps authorization session state and SHOULD 447 save additional information for management of the session (e.g., Acc- 448 Multi-Session-Id, Signaling-Session-Id, authentication data) as part 449 of the session state information. A Signaling-session-Id (if 450 present) SHOULD be used together with the generated Acc-Multi- 451 Session-Id AVP (see Section 6.3) for binding the authorization and 452 the accounting session information in case of end host mobility 453 (i.e., to correlate the Diameter sessions that are initiated for the 454 same signaling session from different QoS NE). 456 The final result of the authorization decision is provided in the 457 QoS-Resources AVP of the QIR message sent by the Authorizing Entity. 458 The QoS information provided via the QIR is installed by the QoS 459 Traffic Control function of the Network Element. In the case of 460 successful enforcement, the Result-Code (= DIAMETER_SUCCESS, (see 461 Section 6.1)) information is provided in the QIA message. 463 One important piece of information from the Authorizing Entity is the 464 authorization lifetime (carried inside the QIR). The authorization 465 lifetime allows the Network Element to determine how long the 466 authorization decision is valid for this particular QoS reservation. 467 A number of factors may influence the authorized session duration, 468 such as the user's subscription plan or currently available credits 469 at the user's account (see Section 4). The authorization duration is 470 time-based as specified in [RFC3588]. For an extension of the 471 authorization period, a new QoS-Install-Request/Answer message or 472 QoS-Authorization-Request/Answer message exchange SHOULD be 473 initiated. Further aspects of QoS authorization session maintenance 474 is discussed in Section 3.3, Section 3.4 and Section 4. 476 The indication of a successful QoS reservation and activation of the 477 data flow, is provided by the QoS-Install-Answer message. Note that 478 the reserved QoS resources reported in the QIA message MAY be 479 different than those initially authorized with the QIR message, due 480 to the QoS signaling specific behavior (e.g., receiver-initiated 481 reservations with One-Path-With-Advertisements) or specific process 482 of QoS negotiation along the data path. 484 In case of xxx = Acounting_Info in the QIR, it indicates the 485 confirmation to an accounting server for successful QoS resource 486 reservation and for final reserved QoS resources (see below). An ACR 487 message reports the parameters of the established QoS state: reserved 488 resources, duration of the reservation, identification of the QoS 489 enabled flow/QoS signaling session and accounting parameters to 490 accounting server. The accounting server acknowledges the reserved 491 QoS resources with the Accounting Answer (ACA) message where the 492 Result-Code is set to 'DIAMETER_SUCCESS'. 494 3.2.3. Discovery and selection of peer Diameter QoS application node 496 The Diameter QoS application node may obtain the location information 497 of its peer nodes (i.e. FQDN or IP address) through static 498 configuration or dynamic discovery as described in [RFC3588]. In 499 particular, the Network Element shall perform the relevant operation 500 for Pull mode; the Authorizing Entity shall perform the relevant 501 operations for Push mode. 503 Upon receipt of a trigger to initiate a new Diameter QoS 504 authorization session, the Diameter QoS application node selects and 505 retrieves the location information of the peer node and based on some 506 index information provided by the resource requesting entity. For 507 instance, it can be the Authorization Entity's ID stored in the 508 authorization token, the end-host's identity (e.g. NAI [RFC2486]) or 509 globally routable IP address. 511 3.3. QoS authorization session re-authorization 513 Client and server-side initiated re-authorizations are considered in 514 the design of the Diameter QoS application. Whether the re- 515 authorization events are transparent for the resource requesting 516 entity or result in specific actions in the QoS signaling protocol is 517 outside the scope of the Diameter QoS application. It is directly 518 dependent on the capabilities of the QoS signaling protocol. 520 There are a number of options for policy rules according to which the 521 NE (AAA client) contacts the Authorizing Entity for re-authorization. 522 These rules depend on the semantics and contents of the QAA message 523 sent by the Authorizing Entity: 525 a. The QAA message contains the authorized parameters of the flow 526 and its QoS and sets their limits (presumably upper). With these 527 parameters the Authorizing Entity specifies the services that the 528 NE can provide and will be financially compensated for. 529 Therefore, any change or request for change of the parameters of 530 the flow and its QoS that do not conform to the authorized limits 531 requires contacting the Authorizing Entity for authorization. 532 b. The QAA message contains authorized parameters of the flow and 533 its QoS. The rules that determine whether parameters' changes 534 require re-authorization are agreed out of band, based on a 535 Service Level Agreement (SLA) between the domains of the NE and 536 the Authorizing Entity. 537 c. The QAA message contains the authorized parameters of the flow 538 and its QoS. Any change or request for change of these 539 parameters requires contacting the Authorizing entity for re- 540 authorization. 542 d. In addition to the authorized parameters of the flow and its QoS, 543 the QAA message contains policy rules that determine the NEs 544 actions in case of change or request for change in authorized 545 parameters. 547 Provided options are not exhaustive. Elaborating on any of the 548 listed approaches is deployment /solution specific and is not 549 considered in the current document. 551 In addition, the Authorizing Entity may use RAR to perform re- 552 authorization with the authorized parameters directly when the re- 553 authorization is triggered by service request or local events/policy 554 rules. 556 3.3.1. Client-Side Initiated Re-Authorization 558 The Authorizing Entity provides the duration of the authorization 559 session as part of the QoS-Authorization-Answer message (QAA). At 560 any time before expiration of this period, a new QoS-Authorization- 561 Request message (QAR) MAY be sent to the Authorizing Entity. The 562 transmission of the QAR MAY be triggered when the Network Element 563 receives a QoS signaling message that requires modification of the 564 authorized parameters of an ongoing QoS session, when authorization 565 lifetime expires or by an accounting event, see Section 4 and 566 Figure 5). 568 Authorizing 569 End-Host Network Element Entity 570 requesting QoS ( Diameter ( Diameter 571 QoS Client) QoS Server) 572 | | | 573 |=====================Data Flow==========================> 574 | | | 575 | +-------+----------+ | 576 | |Authz-time/CC-Time| | 577 | | expires | | 578 | +-------+----------+ | 579 | +- - - - - QAR - - - - - >| 580 | |(QoS-Resources,Cost, | 581 | | QoS-Authz-Data,User-ID)| 582 | +--------+--------------+ 583 NOTE: | | Authorize request | 584 Re-authorization | | Update session data | 585 is transparent to | |/Authz-time,Session-Id/| 586 the End-Host | +--------+--------------+ 587 |< - - - - QAA - - - - - -+ 588 | |(Result-Code,CC-Time,Cost| 589 | |QoS-Resources,Authz-time)| 590 | +-------+---------+ | 591 | |Update QoS state | | 592 | | + | | 593 | | Authz. session | | 594 | | /Authz-time, | | 595 | | CC-Time,Cost/ | | 596 | +-------+---------+ | 597 | | | 598 | +- - - - - ACR - - - - - >| 599 | |(INTRM,QoS-Resources,Cost| 600 | |CC-Time,Acc-Multisess-id)| 601 | | +--------+--------------+ 602 | | |Update of QoS resources| 603 | | |/CC-Time,Cost/ used | 604 | | +--------+--------------+ 605 | |< - - - - ACA - - - - - -+ 606 | | | 607 |=====================Data Flow==========================> 608 | | 610 Figure 5: Client-side initiated QoS re-authorization 612 3.3.2. Server-Side Initiated Re-Authorization 614 The Authorizing Entity MAY initiate a QoS re-authorization by issuing 615 a Re-Auth-Request message (RAR) as defined in the Diameter base 616 protocol [RFC3588], which may include the parameters of the re- 617 authorized QoS state: reserved resources, duration of the 618 reservation, identification of the QoS enabled flow/QoS signaling 619 session for re-installation of the resource state by the QoS Traffic 620 Control function of the Network Element. 622 A Network Element that receives such a RAR message with Session-Id 623 matching a currently active QoS session acknowledges the request by 624 sending the Re-Auth-Answer (RAA) message towards the Authorizing 625 entity. 627 If RAR does not include any parameters of the re-authorized QoS 628 state, the Network Element MUST initiate a QoS re-authorization by 629 sending a QoS-Authorization-Request (QAR) message towards the 630 Authorizing entity. 632 Authorizing 633 End-Host Network Element Entity 634 requesting QoS ( Diameter ( Diameter 635 QoS Client) QoS Server) 636 | | | 637 | | |<-- Trigger -- 638 | | +--------+--------------+ 639 | | | Authorize request | 640 | | | Keep session data | 641 | | |/Authz-time,Session-Id/| 642 | | +--------+--------------+ 643 | | | 644 | |<-- - -- - RAR - - - - - -+ 645 | |(Request,Decision | 646 | |(QoS-Resources,Authz-time)| 647 | +-------+---------+ 648 | |Install QoS state| 649 | | + | 650 | | Authz. session | 651 | | /Authz-time, | 652 | | CC-Time,Cost/ | 653 | +-------+---------+ 654 | + - - - - RAA - - - - - ->| 655 | | (Result-Code, | 656 | | QoS-Resources) | 657 | | +--------+--------------+ 658 | | | Report for successful | 659 | | | QoS reservation | 660 | | |Update of reserved QoS | 661 | | | resources | 662 | | +--------+--------------+ 663 | | | 664 | +- - - - - ACR - - - - - >| 665 | |(INTRM,QoS-Resources,Cost| 666 | |CC-Time,Acc-Multisess-id)| 667 | | +--------+--------------+ 668 | | |Update of QoS resources| 669 | | |/CC-Time,Cost/ used | 670 | | +--------+--------------+ 671 | |< - - - - ACA - - - - - -+ 672 | | | 674 Figure 6: Server-side Initiated QoS re-authorization 676 3.4. Session Termination 678 3.4.1. Client-Side Initiated Session Termination 680 The authorization session for an installed QoS reservation state MAY 681 be terminated by the Diameter client by sending a Session- 682 Termination-Request message (STR) to the Diameter server. This is a 683 Diameter base protocol function and it is defined in [RFC3588]. 684 Session termination can be caused by a QoS signaling messaging 685 requesting deletion of the existing QoS reservation state or it can 686 be caused as a result of a soft-state expiration of the QoS 687 reservation state. After a successful termination of the 688 authorization session, final accounting messages MUST be exchanged 689 (see Figure 7). It should be noted that the two sessions 690 (authorization and accounting) have independent management by the 691 Diameter base protocol, which allows for finalizing the accounting 692 session after the end of the authorization session. 694 Authorizing 695 End-Host Network Element Entity 696 requesting QoS ( Diameter ( Diameter 697 QoS Client) QoS Server) 698 | | | 699 |==Data Flow==>X /Stop of the data flow/ | 700 | | | 701 +---QoS-Reserve---->| | 702 | (Delete QoS +- - - - - STR - - - - - >| 703 | reservation) | +--------+--------------+ 704 | | | Remove authorization | 705 |<--QoS-Response----+ | session state | 706 | | +--------+--------------+ 707 |< - - - - STA - - - - - -+ 708 +-------+--------+ | 709 |Delete QoS state| 710 | Report final | 711 | accounting data| QoS Responder 712 +-------+--------+ Node 713 +----------QoS-Reserve-----....--->| 714 | (Delete QoS | 715 | reservation) 716 | 717 +- - - - - ACR - - - - - >| 718 |(FINAL,QoS-Resources,Cost| 719 |CC-Time,Acc-Multisess-id)| 720 | +--------+--------------+ 721 | | Report for successful | 722 | | end of QoS session | 723 | +--------+--------------+ 724 |< - - - - ACA - - - - - -+ 725 | 726 | QoS Responder 727 | Node 728 |<---------QoS-Response----....----+ 729 | | 731 Figure 7: Client-Side Initiated Session Termination 733 3.4.2. Server-Side Initiated Session Termination 735 At anytime during a session the Authorizing Entity MAY send an Abort- 736 Session-Request message (ASR) to the Network Element. This is a 737 Diameter base protocol function and it is defined in [RFC3588]. 738 Possible reasons for initiating the ASR message to the Network 739 Element are insufficient credits or session termination at the 740 application layer. The ASR message results in termination of the 741 authorized session, release of the reserved resources at the Network 742 Element and transmission of an appropriate QoS signaling message 743 indicating a notification to other Network Elements aware of the 744 signaling session. A final accounting message exchange MUST be 745 triggered as a result of this ASR message exchange (see Figure 8). 747 Authorizing 748 End-Host Network Element Entity 749 requesting QoS ( Diameter ( Diameter 750 QoS Client) QoS Server) 751 | | | 752 |=====================Data Flow==========================> 753 | | 754 | |< - - - - ASR - - - - - -+ 755 | | | 756 |====Data Flow=====>X | QoS Responder 757 | | | Node 758 |<--QoS-Notify------+----------QoS-Reserve-----....--->| 759 | | (Delete QoS | | 760 | reservation) | 761 +-------+--------+ | 762 |Delete QoS state| | 763 | Report final | | 764 | accounting data| | 765 +-------+--------+ | 766 +- - - - - ASA - - - - - >| 767 | +--------+--------------+ 768 | | Remove authorization | 769 | | session state | 770 | +--------+--------------+ 771 +- - - - - ACR - - - - - >| 772 |(FINAL,QoS-Resources,Cost| 773 |CC-Time,Acc-Multisess-id)| 774 | +--------+--------------+ 775 | | Report for successful | 776 | | end of QoS session | 777 | +--------+--------------+ 778 |< - - - - ACA - - - - - -+ 779 | QoS Responder 780 | Node 781 |<---------QoS-Response----....----+ 782 | | 784 Figure 8: Server-Side Initiated Session Termination 786 4. Accounting 788 The Diameter QoS application provides accounting for usage of 789 reserved QoS resources. Diameter QoS accounting has built-in support 790 for online, duration based accounting. This accounting is based on 791 the notion that the Diameter QoS clients are in the best position to 792 determine the cost of those resources. 794 In the Diameter QoS application, the router MAY send a Cost- 795 Information AVP (see [RFC4006]) in the QAR. If the Cost-Information 796 AVP includes a Cost-Unit AVP (see [RFC4006]) then the Cost-Unit 797 SHOULD be "minute". The Cost-Information AVPs represent the cost to 798 allocate the resources requested in the QoS-Resources AVP included in 799 the same QAR message. The QAR MAY optionally contain a Tariff-Time- 800 Change AVP (see [RFC4006]) which is the time at which the cost will 801 change, a second Cost-Information AVP, which is the cost of the 802 reserved resources after the tariff time change, and a second Tariff- 803 Time-Change, which is the time at which the tariff would change 804 again. Either all three or none of these AVPs MUST be present in the 805 QAR. 807 The Resource Authorizing Entity returns a CC-Time AVP (see [RFC4006]) 808 in the QAA message which is the total authorized gate-on time for the 809 service. If the QAR included two Tariff-Time-Change AVPs, the 810 current time plus the CC-Time AVP returned in the QAA MUST NOT exceed 811 the second Tariff-Time-Change AVP from the QAR. Based on information 812 in the Cost-Information AVPs, the Resource Authorizing Entity can use 813 the CC-Time AVP to guarantee that the total cost of the session will 814 not exceed a certain threshold, which allows, for example, support of 815 prepaid users. 817 Each ACR message contains a triplet of QoS-Resources AVP, Cost- 818 Information AVP, and CC-Time AVP. This represents the total time 819 consumed at the given cost for the given resources. Note that an ACR 820 message MUST be sent separately for each interval defined by the 821 Tariff-Time-Change AVPs and the expiration of the CC-Time returned in 822 the QAA (see Figure 5). 824 The Network Element starts an accounting session by sending an 825 Accounting-Request message (ACR) after successful QoS reservation and 826 activation of the data flow (see Figure 2). After every successful 827 re-authorization procedure the Network element MUST initiate an 828 interim accounting message exchange (see Figure 5). After successful 829 session termination the Network element MUST initiate a final 830 exchange of accounting messages for terminating of the accounting 831 session and reporting final records for the usage of the QoS 832 resources reserved (see Figure 7). 834 5. Diameter QoS Authorization Application Messages 836 The Diameter QoS Application requires the definition of new mandatory 837 AVPs and Command-codes (see Section 3 of [RFC3588]). Four new 838 Diameter messages are defined along with Command-Codes whose values 839 MUST be supported by all Diameter implementations that conform to 840 this specification. 842 Command-Name Abbrev. Code Reference 843 QoS-Authz-Request QAR [TBD] Section 5.1 844 QoS-Authz-Answer QAA [TBD] Section 5.2 845 QoS-Install-Request QIR [TBD] Section 5.3 846 QoS-Install-Answer QIA [TBD] Section 5.4 848 In addition, the following Diameter Base protocol messages are used 849 in the Diameter QoS application: 851 Command-Name Abbrev. Code Reference 852 Accounting-Request ACR 271 RFC 3588 853 Accounting-Request ACR 271 RFC 3588 854 Accounting-Answer ACA 271 RFC 3588 855 Re-Auth-Request RAR 258 RFC 3588 856 Re-Auth-Answer RAA 258 RFC 3588 857 Abort-Session-Request ASR 274 RFC 3588 858 Abort-Session-Answer ASA 274 RFC 3588 859 Session-Term-Request STR 275 RFC 3588 860 Session-Term-Answer STA 275 RFC 3588 862 Diameter nodes conforming to this specification MAY advertise support 863 by including the value of TBD in the Auth-Application-Id or the Acct- 864 Application-Id AVP of the Capabilities-Exchange-Request and 865 Capabilities-Exchange-Answer commands, see [RFC3588]. 867 The value of TBD MUST be used as the Application-Id in all QAR/QAA 868 and QIR/QIA commands. 870 The value of TBD MUST be used as the Application-Id in all ACR/ACA 871 commands, because this application defines new, mandatory AVPs for 872 accounting. 874 The value of zero (0) SHOULD be used as the Application-Id in all 875 STR/STA, ASR/ASA, and RAR/RAA commands, because these commands are 876 defined in the Diameter base protocol and no additional mandatory 877 AVPs for those commands are defined in this document. 879 5.1. QoS-Authorization Request (QAR) 881 The QoS-Authorization-Request message (QAR) indicated by the Command- 882 Code field (see Section 3 of [RFC3588]) set to TBD and 'R' bit set in 883 the Command Flags field is used by Network elements to request 884 quality of service related resource authorization for a given flow. 886 The QAR message MUST carry information for signaling session 887 identification, Authorizing Entity identification, information about 888 the requested QoS, and the identity of the QoS requesting entity. In 889 addition, depending on the deployment scenario, an authorization 890 token and credentials of the QoS requesting entity SHOULD be 891 included. 893 The message format, presented in ABNF form [RFC2234], is defined as 894 follows: 896 ::= < Diameter Header: XXX, REQ, PXY > 897 < Session-Id > 898 { Auth-Application-Id } 899 { Origin-Host } 900 { Origin-Realm } 901 { Destination-Realm } 902 { Auth-Request-Type } 903 [ Destination-Host ] 904 [ User-Name ] 905 * [ QoS-Resources ] 906 [ QoS-Authz-Data ] 907 [ Cost-Information ] 908 [ Acc-Multisession-Id ] 909 [ Bound-Auth-Session-Id ] 910 * [ AVP ] 912 5.2. QoS-Authorization Answer (QAA) 914 The QoS-Authorization-Answer message (QAA), indicated by the Command- 915 Code field set to TBD and 'R' bit cleared in the Command Flags field 916 is sent in response to the QoS-Authorization-Request message (QAR). 917 If the QoS authorization request is successfully authorized, the 918 response will include the AVPs to allow authorization of the QoS 919 resources as well as accounting and transport plane gating 920 information. 922 The message format is defined as follows: 924 ::= < Diameter Header: XXX, PXY > 925 < Session-Id > 926 { Auth-Application-Id } 927 { Auth-Request-Type } 928 { Result-Code } 929 { Origin-Host } 930 { Origin-Realm } 931 * [ QoS-Resources ] 932 [ CC-Time ] 933 [ Acc-Multisession-Id ] 934 [ Session-Timeout ] 935 [ Authz-Session-Lifetime ] 936 [ Authz-Grace-Period ] 937 * [ AVP ] 939 5.3. QoS-Install Request (QIR) 941 The QoS-Install Request message (QIR), indicated by the Command-Code 942 field set to TDB and 'R' bit set in the Command Flags field is used 943 by Authorizing entity to install or update the QoS parameters and the 944 flow state of an authorized flow at the transport plane element. 946 The message MUST carry information for signaling session 947 identification or identification of the flow to which the provided 948 QoS rules apply, identity of the transport plane element, description 949 of provided QoS parameters, flow state and duration of the provided 950 authorization. 952 The message format is defined as follows: 954 ::= < Diameter Header: XXX, REQ, PXY > 955 < Session-Id > 956 { Auth-Application-Id } 957 { Origin-Host } 958 { Origin-Realm } 959 { Destination-Realm } 960 { Auth-Request-Type } 961 [ Destination-Host ] 962 * [ QoS-Resources ] 963 [ Session-Timeout ] 964 [ Authz-Session-Lifetime ] 965 [ Authz-Grace-Period ] 966 [ Authz-Session-Volume ] 967 * [ AVP ] 969 5.4. QoS-Install Answer (QIA) 971 The QoS-Install Answer message (QIA), indicated by the Command-Code 972 field set to TBD and 'R' bit cleared in the Command Flags field is 973 sent in response to the QoS-Install Request message (QIR) for 974 confirmation of the result of the installation of the provided QoS 975 reservation instructions. 977 The message format is defined as follows: 979 ::= < Diameter Header: XXX, PXY > 980 < Session-Id > 981 { Auth-Application-Id } 982 { Origin-Host } 983 { Origin-Realm } 984 { Result-Code } 985 * [ QoS-Resources ] 986 * [ AVP ] 988 5.5. Re-Auth-Request (RAR) 990 The Re-Auth-Request message (RAR), indicated by the Command-Code 991 field set to 258 and the 'R' bit set in the Command Flags field, is 992 sent by the Authorizing Entity to the Network Element in order to 993 initiate the QoS re-authorization from DQA server side. 995 If the RAR command is received by the Network Element without any 996 parameters of the re-authorized QoS state, the Network Element MUST 997 initiate a QoS re-authorization by sending a QoS-Authorization- 998 Request (QAR) message towards the Authorizing entity. 1000 The message format is defined as follows: 1002 ::= < Diameter Header: 258, REQ, PXY > 1003 < Session-Id > 1004 { Auth-Application-Id } 1005 { Origin-Host } 1006 { Origin-Realm } 1007 { Destination-Realm } 1008 { Auth-Request-Type } 1009 [ Destination-Host ] 1010 * [ QoS-Resources ] 1011 [ Session-Timeout ] 1012 [ Authz-Session-Lifetime ] 1013 [ Authz-Grace-Period ] 1014 [ Authz-Session-Volume ] 1016 * [ AVP ] 1018 5.6. Re-Auth-Answer (RAA) 1020 The Re-Auth-Answer message (RAA), indicated by the Command-Code field 1021 set to 258 and the 'R' bit cleared in the Command Flags field, is 1022 sent by the Network Element to the Authorizing Entity in response to 1023 the RAR command.. 1025 The message format is defined as follows: 1027 ::= < Diameter Header: 258, PXY > 1028 < Session-Id > 1029 { Auth-Application-Id } 1030 { Origin-Host } 1031 { Origin-Realm } 1032 { Result-Code } 1033 * [ QoS-Resources ] 1034 * [ AVP ] 1036 5.7. Accounting Request (ACR) 1038 The Accounting Request message (ACR), indicated by the Command-Code 1039 field set to 271 and 'R' bit set in the Command Flags field is used 1040 by Network Element to report parameters of the authorized and 1041 established QoS reservation. 1043 The message MUST carry accounting information authorized QoS 1044 resources and its usage, e.g., QoS-Resources, CC-Time, CC-Cost, Acc- 1045 Multi-Session-Id. 1047 The message format is defined as follows: 1049 ::= < Diameter Header: XXX, REQ, PXY > 1050 < Session-Id > 1051 { Acct-Application-Id } 1052 { Destination-Realm } 1053 [ Destination-Host ] 1054 [ Accounting-Record-Type ] 1055 [ Accounting-Record-Number ] 1056 * [ QoS-Resources ] 1057 [ Cost-Information ] 1058 [ CC-Time ] 1059 [ Acc-Multi-Session-Id ] 1060 * [ AVP ] 1062 5.8. Accounting Answer (ACA) 1064 The Accounting Answer message (ACA), indicated by the Command-Code 1065 field set to 271 and 'R' bit cleared in the Command Flags field is 1066 sent in response to the Accounting Request message (ACR) as an 1067 acknowledgment of the ACR message and MAY carry additional management 1068 information for the accounting session, e.g. Acc-Interim-Interval 1069 AVP. 1071 The message format is defined as follows: 1073 ::= < Diameter Header: XXX, PXY > 1074 < Session-Id > 1075 { Acct-Application-Id } 1076 [ Result-Code ] 1077 [ Accounting-Record-Type ] 1078 [ Accounting-Record-Number ] 1079 [ Acc-Multi-Session-Id ] 1080 * [ AVP ] 1082 6. Diameter QoS Authorization Application AVPs 1084 Each of the AVPs identified in the QoS-Authorization-Request/Answer 1085 and QoS-Install-Request/Answer messages and the assignment of their 1086 value(s) is given in this section. 1088 6.1. Diameter Base Protocol AVPs 1090 The Diameter QoS application uses a number of session management 1091 AVPs, defined in the Base Protocol ([RFC3588]). 1093 Attribute Name AVP Code Reference [RFC3588] 1094 Origin-Host 264 Section 6.3 1095 Origin-Realm 296 Section 6.4 1096 Destination-Host 293 Section 6.5 1097 Destination-Realm 283 Section 6.6 1098 Auth-Application-Id 258 Section 6.8 1099 Result-Code 268 Section 7.1 1100 Auth-Request-Type 274 Section 8.7 1101 Session-Id 263 Section 8.8 1102 Authz-Lifetime 291 Section 8.9 1103 Authz-Grace-Period 276 Section 8.10 1104 Session-Timeout 27 Section 8.13 1105 User-Name 1 Section 8.14 1107 The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to 1108 Diameter applications. The value of the Auth-Application-Id for the 1109 Diameter QoS application is TBD. 1111 6.2. Credit Control Application AVPs 1113 The Diameter QoS application provides accounting for usage of 1114 reserved QoS resources. Diameter QoS accounting has built-in support 1115 for online, duration based accounting. For this purpose it re-uses a 1116 number of AVPs defined in Diameter Credit Control application. 1117 [RFC4006]. 1119 Attribute Name AVP Code Reference [RFC4006] 1120 Cost-Information AVP 423 Section 8.7 1121 Unit-Value AVP 445 Section 8.8 1122 Currency-Code AVP 425 Section 8.11 1123 Cost-Unit AVP 424 Section 8.12 1124 CC-Time AVP 420 Section 8.21 1125 Tariff-Time-Change AVP 451 Section 6.20 1127 Usage of the listed AVPs is described in Section 4 1128 Diameter QoS application is designed to independently provide credit 1129 control over the controlled QoS resources. However, deployment 1130 scenarios, where Diameter QoS application is collocated with Diameter 1131 Credit Control application, are not excluded. In such scenarios the 1132 credit control over the QoS resources might be managed by the Credit 1133 control application. Possible interworking approach might be a usage 1134 of Credit-Control AVP (AVP Code 426) with a newly defined value. It 1135 will indicate to the Diameter QoS entities that the credit control 1136 over the QoS resources would be handled in separate session by Credit 1137 Control application. An active cooperation of both applications 1138 would be required but it is not elaborated further in this document. 1140 6.3. Accounting AVPs 1142 The Diameter QoS application uses Diameter Accounting and accounting 1143 AVPs as defined in Section 9 of [RFC3588]. Additional description of 1144 the usage of some of them in the QoS authorization context is 1145 provided: 1147 Attribute Name AVP Code Reference [RFC3588] 1148 Acct-Application-Id 259 Section 6.9 1149 Accounting-Record-Type 480 Section 9.8.1 1150 Accounting-Interim-Interval 85 Section 9.8.2 1151 Accounting-Record-Number 485 Section 9.8.3 1152 Accounting-Realtime-Required 483 Section 9.8.7 1153 Acc-Multi-Session-ID 50 Section 9.8.5 1155 The following AVPs need further explanation: 1157 Acct-Application-Id AVP 1159 The Acct-Application-Id AVP (AVP Code 259)is assigned by IANA to 1160 Diameter applications. The value of the Acct-Application-Id for 1161 the Diameter QoS application is TBD (TBD). 1163 Acc-Multisession-ID 1165 Acc-Multi-Session-ID AVP (AVP Code 50) SHOULD be used to link 1166 multiple accounting sessions together, allowing the correlation of 1167 accounting information. This AVP MAY be returned by the Diameter 1168 server in a QoS-Authorization-Answer message (QAA), and MUST be 1169 used in all accounting messages for the given session. 1171 6.4. Diameter QoS Application Defined AVPs 1173 This document reuses the AVPs defined in Section 4 of 1174 [I-D.ietf-dime-qos-attributes]. 1176 This section lists the AVPs that are introduced specifically for the 1177 Diameter QoS application. The followig new AVPs are defined: Bound- 1178 Auth-Session-Id and the QoS-Authz-Data AVP. 1180 The following table describes the Diameter AVPs newly defined in this 1181 document for usage with the QoS Application, their AVP code values, 1182 types, possible flag values, and whether the AVP may be encrypted. 1184 +-------------------+ 1185 | AVP Flag rules | 1186 +----------------------------------------------|----+---+----+-----+ 1187 | AVP Section | | |SHLD| MUST| 1188 | Attribute Name Code Defined Data Type |MUST|MAY| NOT| NOT| 1189 +----------------------------------------------+----+---+----+-----+ 1190 |QoS-Authz-Data TBD 6.4 Grouped | M | P | | V | 1191 |Bound-Auth-Session-Id TBD 6.4 UTF8String | M | P | | V | 1192 +----------------------------------------------+----+---+----+-----+ 1193 |M - Mandatory bit. An AVP with "M" bit set and its value MUST be | 1194 | supported and recognized by a Diameter entity in order the | 1195 | message, which carries this AVP, to be accepted. | 1196 |P - Indicates the need for encryption for end-to-end security. | 1197 |V - Vendor specific bit that indicates whether the AVP belongs to | 1198 | a address space. | 1199 +------------------------------------------------------------------+ 1201 QoS-Authz-Data 1203 The QoS-Authz-Data AVP (AVP Code TBD) is of type OctetString. It 1204 is a container that carries application session or user specific 1205 data that has to be supplied to the Authorizing entity as input to 1206 the computation of the authorization decision. 1208 Bound-Authentication-Session-Id 1210 The Bound-Authentication-Session AVP (AVP Code TBD) is of type 1211 UTF8String. It carries the id of the Diameter authentication 1212 session that is used for the network access authentication (NASREQ 1213 authentication session). It is used to tie the QoS authorization 1214 request to a prior authentication of the end host done by a co- 1215 located application for network access authentication (Diameter 1216 NASREQ) at the QoS NE. 1218 7. Examples 1220 7.1. Example call flow for pull mode 1222 This section presents an example of the interaction between the end 1223 host and Diameter QoS application entities using Pull mode. The 1224 application layer signaling is, in this example, provided using SIP. 1225 Signaling for a QoS resource reservation is done using the QoS NSLP. 1226 The authorization of the QoS reservation request is done by the 1227 Diameter QoS application (DQA). 1229 End-Host SIP Server Correspondent 1230 requesting QoS (DQA Server) Node 1232 | | | 1233 ..|....Application layer SIP signaling.......|..............|.. 1234 . | Invite (SDP) | | . 1235 . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | . 1236 . | 100 Trying | | . 1237 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| . 1238 . | +-.-.-.....-.-.> . 1239 . | | 180 SDP' | . 1240 . | <-.-.-.....-.-.+ . 1241 . | +--------+--------+ | . 1242 . | |Authorize session| | . 1243 . | | parameters | | . 1244 . | 180 (Session parameters) +--------+--------+ | . 1245 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | . 1246 ..|..........................................|... ..........|.. 1247 | | | 1248 | +------------+ | | 1249 | | NE | | | 1250 | |(DQA Client)| | | 1251 | +------+-----+ | | 1252 | | | | 1253 |QoS NSLP Reserve | | | 1254 +------------------> QAR | | 1255 | (POLICY_DATA>v +- - - - -<>- - - -> | 1256 | QSPEC) v >===>(Destination-Host, | | 1257 | v >=======>QoS-Authz-Data ++------------+ | 1258 | >===========>QoS-Resources, |Authorize | | 1259 | |Cost-Info) |QoS resources| | 1260 | | ++------------+ | 1261 | | QAA | | 1262 | <- - - - -<>- - - -+ | 1263 | |(Result-Code, | | 1264 | |QoS-Resources, | | 1265 | |CC-Time, | | 1266 | |Authz-Lifetime) | | 1267 | +---------+--------+ | | 1268 | |Install QoS state1| | | 1269 | |+ Authz. session | | | 1270 | +---------+--------+ | | 1271 | |QoS NSLP Reserve | 1272 | +---------------..............---------> 1273 | | | 1274 | | QoS NSLP Response| 1275 |QoS NSLP Response <---------------..............---------+ 1276 <------------------+ | 1277 | | QoS NSLP Query| 1278 |QoS NSLP Query <---------------..............---------+ 1279 <------------------+ | 1280 |QoS NSLP Reserve | | 1281 +------------------> QAR | | 1282 | +- - - - -<>- - - -> | 1283 | | +---+---------+ | 1284 | | |Authorize | | 1285 | | |QoS resources| | 1286 | | QAA +---+---------+ | 1287 | <- - - - -<>- - - -+ | 1288 | +---------+--------+ | | 1289 | |Install QoS state2| | 1290 | |+ Authz. session | | 1291 | +---------+--------+ | 1292 | | QoS NSLP Reserve | 1293 | +---------------..............---------> 1294 | | QoS NSLP Response| 1295 |QoS NSLP Response <---------------..............---------+ 1296 <------------------+ | 1297 | | | 1298 /------------------+--Data Flow---------------------------\ 1299 \------------------+--------------------------------------/ 1300 | | | 1302 .-.-.-.-. SIP signaling 1303 --------- QoS NSLP signaling 1304 - - - - - Diameter QoS Application messages 1305 ========= Mapping of objects between QoS and AAA protocol 1307 Figure 23: QoS Authorization Example - Pull Mode 1309 The communication starts with SIP signaling between the two end 1310 points and the SIP server for negotiation and authorization of the 1311 requested service and its parameters (see Figure 23). As a part of 1312 the process, the SIP server verifies whether the user at Host A is 1313 authorized to use the requested service (and potentially the ability 1314 to be charged for the service usage). Negotiated session parameters 1315 are provided to the end host. 1317 Subsequently, Host A initiates a QoS signaling message towards Host 1318 B. It sends a QoS NSLP Reserve message, in which it includes 1319 description of the required QoS (QSPEC object) and authorization data 1320 for negotiated service session (part of the POLICY_DATA object). 1321 Authorization data includes, as a minimum, the identity of the 1322 authorizing entity (e.g., the SIP server) and an identifier of the 1323 application service session for which QoS resources are requested. 1325 A QoS NSLP Reserve message is intercepted and processed by the first 1326 QoS aware Network Element. The NE uses the Diameter QoS application 1327 to request authorization for the received QoS reservation request. 1328 The identity of the Authorizing Entity (in this case the SIP server 1329 that is co-located with a Diameter server) is put into the 1330 Destination-Host AVP, any additional session authorization data is 1331 encapsulated into the QoS-Authz-Data AVP and the description of the 1332 QoS resources is included into QoS-Resources AVP. In addition, the 1333 NE rates the requested QoS resources and announces the charging rate 1334 into the Cost-Information AVP. These AVPs are included into a QoS 1335 Authorization Request message, which is sent to the Authorizing 1336 entity. 1338 A Diameter QAR message will be routed through the AAA network to the 1339 Authorizing Entity. The Authorizing Entity verifies the requested 1340 QoS against the QoS resources negotiated for the service session and 1341 replies with QoS-Authorization answer (QAA) message. It carries the 1342 authorization result (Result-Code AVP) and the description of the 1343 authorized QoS parameters (QoS-Resources AVP), as well as duration of 1344 the authorization session (Authorization-Lifetime AVP) and duration 1345 of the time (CC-Time) for which the end-user should be charged with 1346 the rate announced in the QAR message. The NE interacts with the 1347 traffic control function and installs the authorized QoS resources 1348 and forwards the QoS NSLP Reserve message further along the data 1349 path. 1351 7.2. Example call flow for push mode 1353 This section presents an example of the interaction between the end- 1354 host and Diameter QoS application entities using Push Mode. The 1355 application layer signaling is, in this example, provided using SIP. 1356 Signaling for a QoS resource reservation is done using the QoS NSLP. 1357 The authorization of the QoS reservation request is done by the 1358 Diameter QoS application (DQA). 1360 End-Host NE SIP Server Correspondent 1362 requesting QoS (DQA Client) (DQA Server) Node 1364 | | | | 1365 ..|....Application layer SIP signaling..........|..............|.. 1366 . | Invite(SDP offer)| | | . 1367 . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.> | . 1368 . | 100 Trying | | | . 1369 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | . 1370 . |.............................................|..............| . 1371 | | +---------+-------------+| 1372 | | | Authorize request || 1373 | | | Keep session data || 1374 | | |/Authz-time,Session-Id/|| 1375 | | +---------+-------------+| 1376 | | | | 1377 | |<-- - -- - QIR - -- - -- -+ | 1378 | |(Initial Request,Decision | | 1379 | |(QoS-Resources,Authz-time)| | 1380 | +-------+---------+ | | 1381 | |Install QoS state| | | 1382 | | + | | | 1383 | | Authz. session | | | 1384 | | /Authz-time, | | | 1385 | | CC-Time,Cost/ | | | 1386 | +-------+---------+ | | 1387 | + - - -- - QIA - - - - - ->| | 1388 | | (Result-Code, | | 1389 | | QoS-Resources) | | 1390 | | +----------+------------+ | 1391 | | | Report for successful | | 1392 | | | QoS reservation | | 1393 | | |Update of reserved QoS | | 1394 | | | resources | | 1395 | | +----------+------------+ | 1396 . | | | Invite (SDP) | . 1397 . | | +-.-.-.....-.-.> . 1398 . | 180 (Ringing) | | . 1399 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.<.-.-.-.-.-.-.-+ . 1400 . | | | 200 OK (SDP)| . 1401 . | | <-.-.-.....-.-.+ . 1402 | | +--------+-----------+ | 1403 | | |re-Authorize session| | 1404 | | | parameters | | 1405 | | +--------+-----------+ | 1406 | <- - - - - - RAR - - - - - + | 1407 | +---------+--------+ | | 1408 | |Activate QoS state| | | 1409 | +---------+--------+ | | 1410 | +- - - - - - RAA - - - - - > | 1411 . | 200 (SDP answer) | | | . 1412 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | . 1413 | | | 1414 /------------------+-----Data Flow---------------------------\ 1415 \------------------+-----------------------------------------/ 1416 | | | 1418 .-.-.-.-. SIP signaling 1419 - - - - - Diameter QoS Application messages 1421 Figure 24: QoS Authorization Example - Push Mode 1423 The communication starts with SIP signaling between the two end 1424 points and the SIP server for negotiation and authorization of the 1425 requested service and its parameters (see Figure 24). As a part of 1426 the process, the SIP server verifies whether the user at Host A is 1427 authorized to use the requested service (and potentially the ability 1428 to be charged for the service usage). The DQA server is triggered to 1429 authorize the QoS request based on session parameters (i.e. SDP 1430 offer), initiate a Diameter QoS authorization session and install 1431 authorized QoS state to the Network Element via QIR message. 1433 The DQA server may obtain the info of peer DQA client from pre- 1434 configured information or query the DNS based on Host A's identity or 1435 IP address (In this case a DQA server is co-located with a SIP server 1436 and a DQA client is co-located with a Network element). The identity 1437 of Network Element is put into the Destination-Host AVP, the 1438 description of the QoS resources is included into QoS-Resources AVP, 1439 as well as duration of the authorization session (Authorization- 1440 Lifetime AVP) and duration of the time (CC-Time) for which the end- 1441 user should be charged with the rate announced in the QIR message. 1442 The NE interacts with the traffic control function and reserves the 1443 authorized QoS resources accordingly. 1445 With successful QoS authorization, the SDP offer in SIP Invite is 1446 forwared to Host B. Host B sends back a 18x (ringing) message towards 1447 Host A and processes the SDP. Once Host B accepts the call, it sends 1448 back a 200 OK, in which it includes description of the accepted 1449 session parameters (i.e. SDP answer). 1451 The DQA server may verifies the accepted QoS against the pre- 1452 authorized QoS resources, and sends a Diameter RAR message to the DQA 1453 client in the network element for activating the installed policies 1454 and commit the resource allocation. With successful QoS enforcement, 1455 the 200 OK is forwarded towards Host A. 1457 Note that the examples above show a sender-initiated reservation from 1458 the End-Host towards the corresponding node and a receiver-initiated 1459 reservation from the correspondent node towards the End-Host. 1461 8. IANA Considerations 1463 TBD 1465 9. Security Considerations 1467 TBD 1469 10. Acknowledgements 1471 The authors would like to thank John Loughney and Allison Mankin for 1472 their input to this document. In September 2005 Robert Hancock, 1473 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis and 1474 Elwyn Davies provided a detailed review. Robert also provided us 1475 with good feedback earlier in 2005. Jerry Ash provided us review 1476 comments late 2005/early 2006. Rajith R provided some inputs to the 1477 document early 2007 1479 [Editor's Note: Acknowledgements need to be updated.] 1481 11. Contributors 1483 The authors would like to thank Tseno Tsenov (tseno.tsenov@gmail.com) 1484 and Frank Alfano (falfano@lucent.com) for starting the Diameter 1485 Quality of Service work within the IETF, for your significant draft 1486 contributions and for being the driving force for the first few draft 1487 versions. 1489 [Editor's Note: A bit of history needs to be included here.] 1491 12. Open Issues 1493 Open issues related to this draft are listed at the issue tracker 1494 available at: http://www.tschofenig.com:8080/diameter-qos/ 1496 13. References 1498 13.1. Normative References 1500 [I-D.ietf-dime-qos-attributes] 1501 Korhonen, J., Tschofenig, H., Arumaithurai, M., and M. 1502 Jones, "Quality of Service Attributes for Diameter", 1503 draft-ietf-dime-qos-attributes-03 (work in progress), 1504 November 2007. 1506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1507 Requirement Levels", BCP 14, RFC 2119, March 1997. 1509 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1510 Specifications: ABNF", RFC 2234, November 1997. 1512 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1513 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1515 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1516 "Diameter Network Access Server Application", RFC 4005, 1517 August 2005. 1519 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 1520 Loughney, "Diameter Credit-Control Application", RFC 4006, 1521 August 2005. 1523 13.2. Informative References 1525 [I-D.ietf-nsis-ntlp] 1526 Schulzrinne, H. and R. Hancock, "GIST: General Internet 1527 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 1528 progress), July 2007. 1530 [I-D.ietf-nsis-qos-nslp] 1531 Manner, J., "NSLP for Quality-of-Service Signaling", 1532 draft-ietf-nsis-qos-nslp-15 (work in progress), July 2007. 1534 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1535 Services", RFC 2210, September 1997. 1537 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1538 RFC 2486, January 1999. 1540 [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., 1541 and A. Sastry, "COPS usage for RSVP", RFC 2749, 1542 January 2000. 1544 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 1545 for Policy-based Admission Control", RFC 2753, 1546 January 2000. 1548 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1549 "Remote Authentication Dial In User Service (RADIUS)", 1550 RFC 2865, June 2000. 1552 [RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP) 1553 Extensions for Media Authorization", RFC 3313, 1554 January 2003. 1556 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 1557 "Session Authorization Policy Element", RFC 3520, 1558 April 2003. 1560 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 1561 Session Set-up with Media Authorization", RFC 3521, 1562 April 2003. 1564 [RFC4027] Josefsson, S., "Domain Name System Media Types", RFC 4027, 1565 April 2005. 1567 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1568 Description Protocol", RFC 4566, July 2006. 1570 Authors' Addresses 1572 Glen Zorn (editor) 1574 Phone: 1575 Email: glenzorn@comcast.net 1577 Peter J. McCann 1578 Motorola Labs 1579 1301 E. Algonquin Rd 1580 Schaumburg, IL 60196 1581 USA 1583 Phone: +1 847 576 3440 1584 Email: pete.mccann@motorola.com 1586 Hannes Tschofenig 1587 Nokia Siemens Networks 1588 Otto-Hahn-Ring 6 1589 Munich, Bavaria 81739 1590 Germany 1592 Email: Hannes.Tschofenig@nsn.com 1593 URI: http://www.tschofenig.com 1595 Tina Tsou 1596 Huawei 1597 Shenzhen, 1598 P.R.C 1600 Email: tena@huawei.com 1602 Avri Doria 1603 Lulea University of Technology 1604 Arbetsvetenskap 1605 Lulea, SE-97187 1606 Sweden 1608 Email: avri@ltu.se 1609 Dong Sun 1610 Bell Labs/Alcatel-Lucent 1611 101 Crawfords Corner Rd 1612 Holmdel, NJ 07733 1613 USA 1615 Email: dongsun@alcatel-lucent.com 1617 Full Copyright Statement 1619 Copyright (C) The IETF Trust (2007). 1621 This document is subject to the rights, licenses and restrictions 1622 contained in BCP 78, and except as set forth therein, the authors 1623 retain all their rights. 1625 This document and the information contained herein are provided on an 1626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1628 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1629 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1630 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1633 Intellectual Property 1635 The IETF takes no position regarding the validity or scope of any 1636 Intellectual Property Rights or other rights that might be claimed to 1637 pertain to the implementation or use of the technology described in 1638 this document or the extent to which any license under such rights 1639 might or might not be available; nor does it represent that it has 1640 made any independent effort to identify any such rights. Information 1641 on the procedures with respect to rights in RFC documents can be 1642 found in BCP 78 and BCP 79. 1644 Copies of IPR disclosures made to the IETF Secretariat and any 1645 assurances of licenses to be made available, or the result of an 1646 attempt made to obtain a general license or permission for the use of 1647 such proprietary rights by implementers or users of this 1648 specification can be obtained from the IETF on-line IPR repository at 1649 http://www.ietf.org/ipr. 1651 The IETF invites any interested party to bring to its attention any 1652 copyrights, patents or patent applications, or other proprietary 1653 rights that may cover technology that may be required to implement 1654 this standard. Please address the information to the IETF at 1655 ietf-ipr@ietf.org. 1657 Acknowledgment 1659 Funding for the RFC Editor function is provided by the IETF 1660 Administrative Support Activity (IASA).