idnits 2.17.00 (12 Aug 2021) /tmp/idnits61398/draft-alfano-aaa-qosprot-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1664. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1531 has weird spacing: '...-domain prici...' -- 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 (September 5, 2005) is 6101 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: 'BASE' is mentioned on line 725, but not defined == Missing Reference: 'TBD' is mentioned on line 936, but not defined == Missing Reference: 'Flow-Id' is mentioned on line 1283, but not defined == Missing Reference: 'QoS-Filter-Rule' is mentioned on line 1284, but not defined == Missing Reference: '0-1' is mentioned on line 1315, but not defined == Missing Reference: 'SPI' is mentioned on line 1285, but not defined == Missing Reference: 'QoS-Flow-State' is mentioned on line 1286, but not defined -- Looks like a reference, but probably isn't: '1' on line 1314 == Unused Reference: 'RFC3313' is defined on line 1582, but no explicit reference was found in the text == Unused Reference: 'RFC3521' is defined on line 1590, but no explicit reference was found in the text == Unused Reference: 'RFC4027' is defined on line 1602, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 == Outdated reference: draft-ietf-nsis-qspec has been published as RFC 5975 == Outdated reference: draft-ietf-sipping-trait-authz has been published as RFC 4484 == Outdated reference: A later version (-05) exists of draft-tschofenig-sip-saml-04 -- Obsolete informational reference (is this intentional?): RFC 2327 (Obsoleted by RFC 4566) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) Summary: 5 errors (**), 0 flaws (~~), 18 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Authentication, Authorization and F. Alfano 3 Accounting P. McCann 4 Internet-Draft Lucent Technologies 5 Expires: March 9, 2006 H. Tschofenig 6 T. Tsenov 7 Siemens 8 September 5, 2005 10 Diameter Quality of Service Application 11 draft-alfano-aaa-qosprot-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on March 9, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document describes a Diameter application that performs 45 Authentication, Authorization, and Accounting for Quality of Service 46 (QoS) reservations. This protocol is used by elements along the path 47 of a given application flow to authenticate a reservation request, 48 ensure that the reservation is authorized, and to account for 49 resources consumed during the lifetime of the application flow. 50 Clients that implement the Diameter QoS application contact an 51 authorizing entity/application server that is located somewhere in 52 the network, allowing for a wide variety of flexible deployment 53 models. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Network element functional model . . . . . . . . . . . . . 7 61 3.2. Authorization models . . . . . . . . . . . . . . . . . . . 9 62 3.3. QoS authorization considerations . . . . . . . . . . . . . 12 63 4. Diameter QoS Authorization session establishment and 64 management . . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 4.1. Involved parties . . . . . . . . . . . . . . . . . . . . . 15 66 4.2. Initial QoS authorization (Diameter QoS authorization 67 session establishment) . . . . . . . . . . . . . . . . . . 15 68 4.3. QoS authorization session re-authorization . . . . . . . . 18 69 4.3.1. Client-side initiated Re-Authorization . . . . . . . . 19 70 4.3.2. Server-side initiated Re-Authorization . . . . . . . . 20 71 4.4. Server-side initiated QoS parameter provisioning . . . . . 21 72 4.5. Session Termination . . . . . . . . . . . . . . . . . . . 22 73 4.5.1. Client-side initiated session termination . . . . . . 22 74 4.5.2. Server-side initiated session termination . . . . . . 23 75 5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 6. Diameter QoS authorization application Messages . . . . . . . 27 77 6.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 28 78 6.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 28 79 6.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 29 80 6.4. QoS-Install Answer (QAA) . . . . . . . . . . . . . . . . . 30 81 6.5. Accounting Request (ACR) . . . . . . . . . . . . . . . . . 30 82 6.6. Accounting Answer (ACA) . . . . . . . . . . . . . . . . . 31 83 7. Diameter QoS Authorization Application AVPs . . . . . . . . . 32 84 7.1. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 32 85 7.2. Credit Control application AVPs . . . . . . . . . . . . . 32 86 7.3. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 33 87 7.4. Diameter QoS Application Defined AVPs . . . . . . . . . . 33 88 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 91 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 93 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43 94 12.2. Informative References . . . . . . . . . . . . . . . . . . 43 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 96 Intellectual Property and Copyright Statements . . . . . . . . . . 46 98 1. Introduction 100 To meet the Quality of Service needs of applications such as Voice- 101 over-IP in a heavily loaded network, packets belonging to real-time 102 application flows must be identified and segregated from other 103 traffic to ensure that bandwidth, delay, and loss rate requirements 104 are met. In addition, new flows should not be added to the network 105 when it is at or near capacity, which would result in degradation of 106 quality for all flows carried by the network. 108 In some cases, these goals can be achieved with mechanisms such as 109 differentiated services and/or end-to-end congestion and admission 110 control. However, when bandwidth is scarce and must be carefully 111 managed, such as in cellular networks, or when applications and 112 transport protocols lack the capability to perform end-to-end 113 congestion control, explicit reservation techniques are required. In 114 these cases, the endpoints will send reservation requests to edge 115 and/or interior nodes along the communication path. In addition to 116 verifying whether resources are available, the recipient of a 117 reservation request must also authenticate and authorize the request, 118 especially in an environment where the endpoints are not trusted. In 119 addition, these nodes will generate accounting information about the 120 resources used and attribute usage to the requesting endpoints. This 121 will enable the owner of the network element to generate usage- 122 sensitive billing records and to understand how to allocate new 123 network capacity. 125 A variety of protocols could be used to make a QoS request, including 126 RSVP [RFC2210], NSIS [I-D.ietf-nsis-qos-nslp], link-specific 127 signaling or even SIP/SDP [RFC2327]. This document aims to be 128 agnostic to the used QoS signaling protocol and to the signaled QoS 129 model. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 The following terms are used in this document: 139 Application Server 141 An application server is a network entity that exchanges signaling 142 messages with an application endpoint. It may be a source of 143 authorization for QoS-enhanced application flows. For example, a 144 SIP server is one kind of application server. 146 Application Endpoint 148 An application endpoint is an entity in an end user device that 149 exchanges signaling messages with application servers or directly 150 with other application endpoints. Based on the result of this 151 signaling, the endpoint will make a request for QoS from the 152 network. For example, a SIP User Agent is one kind of application 153 endpoint. 155 Authorizing Entity 157 The authorizing entity is that entity responsible for authorizing 158 QoS requests for a particular application flow or aggregate. This 159 may be a Diameter server (with a subscriber database) or an 160 application server acting as a Diameter server. 162 AAA Cloud 164 A network of AAA proxy/broker arrangements. 166 Network Element (NE) 168 QoS aware router that acts as Diameter client that implements the 169 Diameter QoS application in the context of this document. For 170 almost all scenarios this entity triggers the protocol interaction 171 described in this document. This entity corresponds to the Policy 172 Enforcement Point (PEP) (see [RFC2753]) from a functionality point 173 of view. 175 3. Framework 177 The Diameter QoS application runs between a network element receiving 178 QoS reservation requests (acting as a AAA client) and the resource 179 authorizing entity (acting as a AAA server). A high-level picture of 180 the resulting architecture is shown in Figure 1. 182 +-----------------+ 183 | Authorizing | 184 | Entity | 185 |(Diameter Server)| 186 +-------+---------+ 187 | 188 | 189 /\-----+-----/\ 190 //// \\\\ 191 || AAA Cloud || 192 | (Diameter application) | 193 || || 194 \\\\ //// 195 \-------+-----/ 196 | 197 +---+--+ +-----+----+ +---+--+ 198 | | | NE | | | Application 199 + NE +===+(Diameter +===+ NE +=============>> 200 | | | Client) | | | Flow 201 +------+ +----------+ +------+ 203 Figure 1: An Architecture supporting QoS-AAA 205 Figure 1 depicts network elements through which application flows 206 need to pass, a cloud of AAA servers, and an authorizing entity. 207 Note that there may be more than one router that needs to interact 208 with the AAA cloud along the path of a given application flow, 209 although the figure only depicts one for clarity. QoS aware network 210 elements will request authorization from the AAA cloud based on an 211 incoming QoS reservation request, which will route the request, for 212 example, to the home network where the home authorizing entity will 213 return the result of the authorization decision. 215 In more complex deployment models, the authorization will be based on 216 dynamic application state, so that the request must be authenticated 217 and authorized based on information from one or more application 218 servers. If defined properly, the interface between the routers and 219 AAA cloud would be identical in both cases. Routers are therefore 220 insulated from the details of particular applications and need not 221 know that application servers are involved at all. Also, the AAA 222 cloud would naturally encompass business relationships such as those 223 between network operators and third-party application providers, 224 enabling flexible intra- or inter-domain authorization, accounting, 225 and settlement. 227 3.1. Network element functional model 229 Figure 2 depicts a logical operational model of resource management 230 in a router. 232 +-----------------------------------------------------+ 233 | DIAMETER Client | 234 | Functionality | 235 | +---------------++---------------++---------------+ | 236 | | User || Authorization || Accounting | | 237 | | Authentication|| of QoS || for QoS | | 238 | +---------------+| Requests || Traffic | | 239 | +---------------++---------------+ | 240 +-----------------------------------------------------+ 241 ^ ^ 242 v v 243 +--------------+ +----------+ 244 |QoS Signaling | | Resource | 245 |Msg Processing|<<<<<>>>>>>>|Management| 246 +--------------+ +----------+ 247 . ^ | * ^ 248 | v . * ^ 249 +-------------+ * ^ 250 |Signaling msg| * ^ 251 | Processing | * V 252 +-------------+ * V 253 | | * V 254 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 255 . . * V 256 | | * ............................. 257 . . * . Traffic Control . 258 | | * . +---------+. 259 . . * . |Admission|. 260 | | * . | Control |. 261 +----------+ +------------+ . +---------+. 262 <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 263 | Packet | | Interface | .+----------+ +---------+. 264 ===>|Processing|====| Selection |===.| Packet |====| Packet |.=> 265 | | |(Forwarding)| .|Classifier| Scheduler|. 266 +----------+ +------------+ .+----------+ +---------+. 267 ............................. 268 <.-.-> = signaling flow 269 =====> = data flow (sender --> receiver) 270 <<<>>> = control and configuration operations 271 ****** = routing table manipulation 273 Figure 2: Network element functional model 275 Processing of incoming QoS reservation requests includes three 276 actions: admission control, authorization and resource reservation. 278 The admission control function provides information for available 279 resources and determines whether there are enough resources to 280 fulfill the request. Authorization is performed by the Diameter 281 client function which involves contacting an authorization entity 282 through the AAA cloud shown in Section 3. If both checks are 283 successful, the authorized QoS parameters are set in the packet 284 classifier and the packet scheduler. Note that the parameters passed 285 to the Traffic Control function may be different from requested QoS 286 (depending on the authorization decision). Once the requested 287 resource is granted, the Resource Management function provides 288 accounting information to the Authorizing entity using the Diameter 289 client function. 291 3.2. Authorization models 293 Three fundamental models for authorizing QoS reservations exist: one 294 two-party and two three party models. See [I-D.tschofenig-nsis-aaa- 295 issues] and in [I-D.tschofenig-nsis-qos-authz-issues] for a more 296 detailed discussion of authorization models and the impact for QoS 297 reservations. From the Diameter QoS application's point of view 298 these models differ in type of information that need to be carried. 299 Here we focus on the 'Three party model' (Figure 3) and the Token 300 based three party model' (Figure 4). With the 'Two party model' the 301 QoS resource requesting entity is authenticated by the Network 302 Element and the authorization decision is made either locally at the 303 Network Element itself or offloaded to a trusted entity (most likely 304 within the same administrative domain). In the former case no 305 Diameter QoS protocol interaction is required. 307 +--------------+ 308 | Entity | 309 | authorizing | <......+ 310 | resource | . 311 | request | . 312 +------------+-+ . 313 --^----------|-- . . 314 ///// | | \\\\\ . 315 // | | \\ . 316 | QoS | QoS AAA | QoS |. 317 | authz| protocol |authz |. 318 | req.| | res. |. 319 \\ | | // . 320 \\\\\ | | ///// . 321 QoS --|----------v-- . . 322 +-------------+ request +-+------------+ . 323 | Entity |----------------->| NE | . 324 | requesting | | performing | . 325 | resource |granted / rejected| QoS | <.....+ 326 | |<-----------------| reservation | financial 327 +-------------+ +--------------+ settlement 329 Figure 3: Three Party Model 331 With the 'Three party model' a QoS reservation request that hits the 332 Network Element is forwarded to the Authorizing Entity (e.g., the 333 user's home network), where the authorization decision is made. A 334 business relationship, such as a roaming agreement, between the 335 visited network and the home network ensures that the visited network 336 is compensated for the consumed resources of the user via the home 337 network. 339 financial settlement 340 ...........................+ 341 Authorization V ------- . 342 Token Request +--------------+ / QoS AAA \ . 343 +-------------->| | / protocol \ . 344 | | Authorizing +--------------+ \ . 345 | | Entity | | | | . 346 | +------+ |<--+----+ | | . 347 | | +--------------+ |QoS | |QoS |. 348 | | |authz| |authz|. 349 | |Authorization |req.+| |res. |. 350 | |Token |Token| | |. 351 | | | | | . | . 352 | | \ | | . / . 353 | | \ | | / . 354 | | QoS request |-----V . . 355 +-------------+ + Authz. Token +--------+-----+ . 356 | Entity |----------------->| NE | . 357 | requesting | | performing | . 358 | resource |granted / rejected| QoS | <....+ 359 | |<-----------------| reservation | 360 +-------------+ +--------------+ 362 Figure 4: Token based Three Party Model 364 The 'Token based Three Party model' is applicable to environments 365 where a previous protocol interaction is used to request 366 authorization tokens to assist the authorization process at the 367 Network Element or the Authorizing Entity. 369 The QoS resource requesting entity may be involved in an application 370 layer protocol interaction, for example using SIP, with the 371 Authorizing Entity. As part of this interaction, authentication and 372 authorization at the application layer might take place. As a result 373 of a successful authorization decision, which might involve the 374 user's home AAA server, an authorization token is generated by the 375 Authorizing Entity (e.g., the SIP proxy and an entity trusted by the 376 SIP proxy) and returned to the end host for inclusion into the QoS 377 signaling protocol. The authorization token will be used by a 378 Network Element that receives the QoS signaling message to authorize 379 the QoS request. Alternatively, the Diameter QoS application will be 380 used to forward the authorization token to the user's home network. 381 The authorization token allows the authorization decision performed 382 at the application layer protocol run to be associated with a 383 corresponding QoS signaling session. Note that the authorization 384 token might either refer to established state concerning the 385 authorization decision or the token might itself carry the authorized 386 parameters (protected by a digital signature or a keyed message 387 digest to prevent tampering). In the latter case the authorization 388 token may contain several pieces of information pertaining to the 389 authorized application session, but at minimum it should contain: 390 o An identifier of the Authorizing Entity (for example, of an 391 application server) that issued the authorization token, 392 o An identifier referring to a specific application protocol session 393 for which the token was issued and 394 o A keyed message digest or digital signature protecting the content 395 of the authorization token. 397 A possible structure for the authorization token and the policy 398 element carrying it are proposed in context of RSVP [RFC3520], with 399 the OSP [ETSI-OSP] or as outlined in [I-D.ietf-sipping-trait-authz] 400 and [I-D.tschofenig-sip-saml]. 402 3.3. QoS authorization considerations 404 A QoS authorization application must meet a number of requirements 405 applicable to a diverse set of networking environments and services. 406 It should be compliant with different deployment scenarios with 407 specific QoS signaling models and security issues. Satisfying the 408 requirements listed below requirements while interworking with QoS 409 signaling protocols, a Diameter QoS application should accommodate 410 the capabilities of the QoS signaling protocols rather than 411 introducing functional requirements on them. A list of requirements 412 for a QoS authorization application is provided here: 413 Inter-domain support 415 In particular, users may roam outside their home network, leading 416 to a situation where the network element and authorizing entity 417 are in different administrative domains. 419 Identity-based Routing 421 The QoS AAA protocol MUST route AAA requests to the Authorizing 422 Entity. 424 Flexible Authentication Support 426 The QoS AAA protocol MUST support a variety of different 427 authentication protocols for verification of authentication 428 information present in QoS signaling messages. The support for 429 these protocols MAY be provided indirectly by tying the signaling 430 communication for QoS to a previous authentication protocol 431 exchange (e.g., using network access authentication). 433 Making an Authorization Decision 435 The QoS AAA protocol MUST exchange sufficient information between 436 the authorizing entity and the enforcing entity (and vice versa) 437 to compute an authorization decision and to execute this decision. 439 Triggering an Authorization Process 441 The QoS AAA protocol MUST allow periodic and event triggered 442 execution of the authorization process, originated at the 443 enforcing entity or even at the authorizing entity. 445 Associating QoS Reservations and Application State 447 The QoS AAA protocol MUST carry information sufficient for an 448 application server to identify the appropriate application session 449 and associate it with a particular QoS reservation. 451 Dynamic Authorization 453 It MUST be possible for the QoS AAA protocol to push updates 454 towards the network element(s) from authorizing entities. 456 Bearer Gating 458 The QoS AAA protocol MUST allow the authorizing entity to gate 459 (i.e., enable/disable) authorized application flows based on e.g., 460 application state transitions. 462 Accounting Records 464 The QoS AAA protocol MUST define QoS accounting records containing 465 duration, volume (byte count) usage information and description of 466 the QoS attributes (e.g., bandwidth, delay, loss rate) that were 467 supported for the flow. 469 Sending Accounting Records 471 The network element MUST send accounting records for a particular 472 application flow to the authorizing entity for that flow or to 473 another entity identified by the authorizing entity. 475 Failure Notification 477 The QoS AAA protocol MUST allow the network element to report 478 failures(such as loss of connectivity due to movement of a mobile 479 node or other reasons for packet loss) to the authorizing entity. 481 Accounting Correlation 483 The QoS AAA protocol MUST support the exchange of sufficient 484 information to allow for correlation between accounting records 485 generated by the network elements and accounting records generated 486 by an application server. 488 Interaction with other AAA Applications 489 Interaction with other AAA applications such as Diameter NASREQ 490 [RFC4005] is required for exchange of authorization, 491 authentication and accounting information. 493 In deployment scenarios, where authentication of the QoS reservation 494 requesting entity (e.g., the user) is done by means outside the 495 Diameter QoS application protocol interaction the Authorizing Entity 496 is contacted only with a request for QoS authorization. 497 Authentication might have taken place already via the interaction 498 with the Diameter NASREQ application or as part of the QoS signaling 499 protocol (e.g., TLS handshake in GIST [I-D.ietf-nsis-ntlp]). 501 Authentication of the QoS reservation requesting entity to the 502 Authorizing Entity is necessary if a particular Diameter QoS 503 application protocol run cannot be related (of if there is no 504 intention to relate it) to a prior authentication. In this case the 505 Authorizing Entity MUST authenticate the QoS reservation requesting 506 entity in order to authorize the QoS request as part of the Diameter 507 QoS protocol interaction. 509 4. Diameter QoS Authorization session establishment and management 511 4.1. Involved parties 513 Authorization models supported by this application include three 514 parties: 515 o Resource requesting entity 516 o Network Elements (Diameter QoS clients) 517 o Authorizing Entity (Diameter QoS server) 518 Note that the QoS resource requesting entity is only indirectly 519 involved in the message exchange. This entity provides the trigger 520 to initiate the Diameter QoS protocol interaction by transmitting QoS 521 signaling messages. The Diameter QoS application is only executed 522 between the Network Element (i.e., Diameter QoS client) and the 523 Authorizing Entity (i.e., Diameter QoS server). 525 The QoS resource requesting entity may communicate with the 526 Authorizing Entity using application layer signaling for negotiation 527 of service parameters. As part of this application layer protocol 528 interaction, for example using SIP, authentication and authorization 529 might take place (see Figure 4). This message exchange is, however, 530 outside the scope of this document. This protocol communication 531 might be accomplished using the NSIS protocol suite, RSVP or a link 532 layer signaling protocol. A description of these protocols is also 533 outside the scope of this document and a tight coupling with these 534 protocols is not desired since this applications aims to be generic. 536 4.2. Initial QoS authorization (Diameter QoS authorization session 537 establishment) 539 Figure 5 shows the protocol interaction between a resource requesting 540 entity, a Network Element and the Authorizing Entity. 542 A request for a QoS reservation received by a Network Element 543 initiates a Diameter QoS authorization session. The Network Element 544 generates a QoS-Authorization-Request message (QAR) in which it maps 545 required objects from the QoS signaling message to Diameter AVPs. 546 Authorizing Entity's identity (Destination-Host AVP), pointer to the 547 application session and/or identity and credentials of the QoS 548 resource requesting entity (QoS-Authentication-Data, User-Name-ID 549 AVPs), requested QoS parameters (QSPEC AVP), signaling session 550 identifier and/or QoS enabled data flows identifiers (Signaling- 551 Session-Id and Flows AVPs) MAY be encapsulated into respective 552 Diameter AVPs and included into the Diameter message sent to the 553 Authorizing Entity. The QAR is sent to a Diameter server that can 554 either be in the realm of the QoS requesting entity or also be an 555 application server. 557 When the Diameter QoS server receives the QAR authorization 558 processing starts. Based on the information in the QoS- 559 Authentication-Data, User-Name-ID and QoS-Authorized-Resources AVPs 560 the server determines the authorized QoS resources and flow state 561 (enabled/disabled) from locally available information (e.g., policy 562 information that may be previously established as part of an 563 application layer signaling exchange, or the user's subscription 564 profile). The authorization decision is then reflected in the 565 response returned to the Diameter client with the QoS-Authorization- 566 Answer message (QAA). 568 Authorizing 569 End-Host Network Element Entity 570 requesting QoS ( Diameter ( Diameter 571 QoS Client) QoS Server) 572 | | | 573 +---QoS-Reserve---->| | 574 | +- - - - - QAR - - - - - >| 575 | |(QoS-Resources,Cost, | 576 | | QoS-Auth-Data,User-ID)| 577 | | +--------+--------------+ 578 | | | Authorize request | 579 | | | Keep session data | 580 | | |/Authz-time,Session-Id/| 581 | | +--------+--------------+ 582 | |< - - - - QAA - - - - - -+ 583 | |(Result-Code,CC-Time,Cost| 584 | |QoS-Resources,Authz-time)| 585 | +-------+---------+ 586 | |Install QoS state| 587 | | + | 588 | | Authz. session | 589 | | /Authz-time, | 590 | | CC-Time,Cost/ | 591 | +-------+---------+ 592 | +----------QoS-Reserve---------------> 593 | | 594 | |<---------QoS-Response--------------- 595 |<--QoS-Response----+ 596 | | 597 |=====================Data Flow==========================> 598 | | 599 | +- - - - - ACR - - - - - >| 600 | |(START,QoS-Resources,Cost| 601 | |CC-Time,Acc-Multisess-id)| 602 | | +--------+--------------+ 603 | | | Report for successful | 604 | | | QoS reservation | 605 | | |Update of reserved QoS | 606 | | | resources | 607 | | +--------+--------------+ 608 | |< - - - - ACA - - - - - -+ 609 | | | 611 Figure 5: Initial QoS request authorization 613 The Authorizing Entity keeps authorization session state and SHOULD 614 save additional information for management of the session (e.g., Acc- 615 Multi-Session-Id, Signaling-Session-Id, authentication data) as part 616 of the session state information. A Signaling-session-Id (if 617 present) SHOULD be used together with the generated Acc-Multi- 618 Session-Id AVP for binding the authorization and the accounting 619 session information in case of end host mobility (i.e., to correlate 620 the Diameter sessions that are initiated for the same signaling 621 session from different QoS NE). 623 The final result of the authorization request is provided in the 624 Result-Code AVP of the QAA message sent by the Authorizing Entity. 625 In case of successful authorization (i.e., Result-Code = 626 DIAMETER_LIMITED_SUCCESS), information about the authorized QoS 627 resources and the status of the authorized flow (enabled/disabled) is 628 provided in the QoS-Authorization-Resources AVP of the QAA message. 629 The QoS information provided via the QAA is installed by the QoS 630 Traffic Control function of the Network Element (see Figure 2). 632 One important piece of information returned from the Authorizing 633 Entity is the authorization lifetime (carried inside the QAA). The 634 authorization lifetime allows the Network Element to determine how 635 long the authorization decision is valid for this particular QoS 636 reservation. A number of factors may influence the authorized 637 session duration, such as the user's subscription plan or currently 638 available credits at the user's account (see Section 5). The 639 authorization duration is time-based as specified in [RFC3588]. For 640 an extension of the authorization period, a new QoS-Authorization- 641 Request/Answer message exchange SHOULD be initiated. Further aspects 642 of QoS authorization session maintenance is discussed in Section 4.3, 643 Section 4.5 and Section 5. 645 The indication of a successful QoS reservation and activation of the 646 data flow, is done by the transmission of an Accounting Request (ACR) 647 message, which reports the parameters of the established QoS state: 648 reserved resources, duration of the reservation, identification of 649 the QoS enabled flow/QoS signaling session and accounting parameters. 650 The Diameter QoS server acknowledges the reserved QoS resources with 651 the Accounting Answer (ACA) message where the Result-Code is set to 652 'DIAMETER_SUCCESS'. Note that the reserved QoS resources reported in 653 the ACR message MAY be less than those initially authorized with QAA 654 message, due to the QoS signaling specific behavior (e.g., receiver- 655 initiated reservations with One-Path-With-Advertisements) specific 656 process of QoS negotiation along the data path. 658 4.3. QoS authorization session re-authorization 660 Client and server-side initiated re-authorizations are considered in 661 the design of the Diameter QoS application. Whether the re- 662 authorization events are transparent for the resource requesting 663 entity or result in specific actions in the QoS signaling protocol is 664 outside the scope of the Diameter QoS application. It is directly 665 dependent on the capabilities of the QoS signaling protocol. 667 4.3.1. Client-side initiated Re-Authorization 669 The Authorizing Entity provides the duration of the authorization 670 session as part of the QoS-Authorization-Answer message (QAA). At 671 any time before expiration of this period, a new QoS-Authorization- 672 Request message (QAR) MAY be sent to the Authorizing Entity. The 673 transmission of the QAR MAY be triggered when the Network Element 674 receives a QoS signaling message with the semantic of modifying an 675 ongoing authorized QoS session or when authorization lifetime expires 676 or by an accounting event (see Section 5)(Figure 6) 677 Authorizing 678 End-Host Network Element Entity 679 requesting QoS ( Diameter ( Diameter 680 QoS Client) QoS Server) 681 | | | 682 |=====================Data Flow==========================> 683 | | | 684 | +-------+----------+ | 685 | |Authz-time/CC-Time| | 686 | | expires | | 687 | +-------+----------+ | 688 | +- - - - - QAR - - - - - >| 689 | |(QoS-Resources,Cost, | 690 | | QoS-Auth-Data,User-ID)| 691 | +--------+--------------+ 692 NOTE: | | Authorize request | 693 Re-authorization | | Update session data | 694 is transparent to | |/Authz-time,Session-Id/| 695 the End-Host | +--------+--------------+ 696 |< - - - - QAA - - - - - -+ 697 | |(Result-Code,CC-Time,Cost| 698 | |QoS-Resources,Authz-time)| 699 | +-------+---------+ | 700 | |Update QoS state | | 701 | | + | | 702 | | Authz. session | | 703 | | /Authz-time, | | 704 | | CC-Time,Cost/ | | 705 | +-------+---------+ | 706 | | | 707 | +- - - - - ACR - - - - - >| 708 | |(INTRM,QoS-Resources,Cost| 709 | |CC-Time,Acc-Multisess-id)| 710 | | +--------+--------------+ 711 | | | Update of used QoS | 712 | | |resources/CC-Time,Cost/| 713 | | +--------+--------------+ 714 | |< - - - - ACA - - - - - -+ 715 | | | 716 |=====================Data Flow==========================> 717 | | 719 Figure 6: QoS request re-authorization 721 4.3.2. Server-side initiated Re-Authorization 723 The Authorizing Entity MAY optionally initiate a QoS re-authorization 724 by issuing a Re-Auth-Request message (RAR) as defined in the Diameter 725 base protocol [BASE]. A Network Element client that receives such a 726 RAR message with Session-Id matching a currently active QoS session 727 acknowledges the request by sending the Re-Auth-Answer (RAA) message 728 and MUST initiate a QoS reservation re-authorization by sending a 729 QoS-Authorization-Request (QAR) message towards the Authorizing 730 entity. 732 4.4. Server-side initiated QoS parameter provisioning 734 The Authorizing Entity is enabled to update installed QoS parameters 735 and flow state at the Network Element by sending a QoS-Install 736 Request message (QIR). Network Elements MUST apply the updates and 737 respond with an QoS-Install Answer message (QIA). This 738 functionality, for example, allows to update already authorized flow 739 status of an established QoS reservation due to a change at the 740 application layer session (Figure 7). 742 Authorizing 743 End-Host Network Element Entity 744 requesting QoS ( Diameter ( Diameter 745 QoS Client) QoS Server) 746 | | | 747 +===================+=Data Flow==========================> 748 | | +--------+--------------+ 749 | | | Gate close event | 750 | | +--------+--------------+ 751 | |< - - - - QIR - - - - - -+ 752 | |(QoS-Resources[QoS-Flow- | 753 | | -State=CLOSE]) | 754 | +-------+---------+ | 755 | |Update QoS state | | 756 | | + | | 757 | | Authz. session | | 758 | |/QoS-Flow-State= | | 759 | | CLOSE/ | | 760 | +-------+---------+ | 761 +====Data Flow=====>X | 762 | +- - - - - QAA - - - - - >| 763 | | (Result-Code) | 765 Figure 7: Server-side initiated QoS parameter provisioning 767 The Authorizing Entity MAY initiate QoS authorization session 768 establishment and QoS reservation state installation (prior to a 769 request from a Network Element). Such function requires that the 770 Authorizing Entity has knowledge of specific information identifying 771 the Network Element that should be contacted and the data flow for 772 which the QoS reservation should be established. 774 4.5. Session Termination 776 4.5.1. Client-side initiated session termination 778 A QoS authorization session MAY be terminated by the Diameter client 779 by sending a Session-Termination-Request message (STR) to the 780 Diameter server. This is a Base Diameter protocol functionality and 781 it is defined in [RFC3588]. Session termination can be caused by a 782 QoS signaling messaging requesting to delete an existing QoS 783 reservation state or it can be caused as a result of a loss of bearer 784 report. After a successful termination of the authorization session, 785 final accounting messages MUST be exchanged (Figure 8). 787 Authorizing 788 End-Host Network Element Entity 789 requesting QoS ( Diameter ( Diameter 790 QoS Client) QoS Server) 791 | | | 792 |==Data Flow==>X /Stop of the data flow/ | 793 | | | 794 +---QoS-Reserve---->| | 795 | (TearOn) +- - - - - STR - - - - - >| 796 | | +--------+--------------+ 797 |<--QoS-Response----+ | Remove session state | 798 | | +--------+--------------+ 799 |< - - - - STA - - - - - -+ 800 +-------+-----------+ | 801 |Tear down QoS state| 802 | Report final | 803 | accounting data | 804 +-------+-----------+ 805 +----------QoS-Reserve---------------> 806 | (TearOn) 807 | 808 +- - - - - ACR - - - - - >| 809 |(FINAL,QoS-Resources,Cost| 810 |CC-Time,Acc-Multisess-id)| 811 | +--------+--------------+ 812 | | Report for successful | 813 | | end of QoS session | 814 | +--------+--------------+ 815 |< - - - - ACA - - - - - -+ 816 | 817 | 818 |<---------QoS-Response--------------- 819 | 821 Figure 8: Client-side initiated session termination 823 4.5.2. Server-side initiated session termination 825 At anytime during a session the Authorizing Entity MAY send an Abort- 826 Session-Request message (ASR) to the Network Element. This is a Base 827 Diameter protocol functionality and it is defined in [RFC3588]. 828 Possible reasons for initiating the ASR message to the Network 829 Element are insufficient credits or session termination at the 830 application layer. The ASR message results in termination of the 831 authorized session, release of the reserved resources at the Network 832 Element and transmission of an appropriate QoS signaling message 833 indicating a notification to other Network Elements aware of the 834 signaling session. A final accounting message exchanges MUST be 835 triggered as a result of this ASR message exchange (Figure 9). 837 Authorizing 838 End-Host Network Element Entity 839 requesting QoS ( Diameter ( Diameter 840 QoS Client) QoS Server) 841 | | | 842 |=====================Data Flow==========================> 843 | | 844 | |< - - - - ASR - - - - - -+ 845 | | | 846 |====Data Flow=====>X | 847 | | | 848 |<--QoS-Notify------+----------QoS-Reserve---------------> 849 | | (TearOn) | 850 +-------+-----------+ | 851 |Tear down QoS state| | 852 | Report final | | 853 | accounting data | | 854 +-------+-----------+ | 855 +- - - - - ASA - - - - - >| 856 | +--------+--------------+ 857 | | Remove session state | 858 | +--------+--------------+ 859 +- - - - - ACR - - - - - >| 860 |(FINAL,QoS-Resources,Cost| 861 |CC-Time,Acc-Multisess-id)| 862 | +--------+--------------+ 863 | | Report for successful | 864 | | end of QoS session | 865 | +--------+--------------+ 866 |< - - - - ACA - - - - - -+ 867 | 868 | 869 |<---------QoS-Response--------------- 870 | 872 Figure 9: Server-side initiated session termination 874 5. Accounting 876 The Diameter QoS application provides accounting for usage of 877 reserved QoS resources. Diameter QoS accounting has built-in support 878 for online, duration based accounting. This accounting is based on 879 the notion that the routers making the QoS Authorization Request 880 (Diameter QoS clients) are in the best position to determine the cost 881 of those resources. This cost represents the financial settlement 882 that will be ultimately demanded by the router if the Resource 883 Authorizing Entity authorizes the reservation. 885 In the Diameter QoS application, the router MAY send a Cost- 886 Information AVP ([RFC4006]) in the QAR. If the Cost-Information AVP 887 includes a Cost-Unit AVP ([RFC4006]) then the Cost-Unit SHOULD be 888 "minute". The Cost-Information AVPs represent the cost to allocate 889 the resources requested in the QoS-Authorization-Resources AVP 890 included in the same QAR message. The QAR MAY optionally contain a 891 Tariff-Time-Change AVP ([RFC4006]) which is the time at which the 892 cost will change, a second Cost-Information AVP, which is the cost of 893 the reserved resources after the tariff time change, and a second 894 Tariff-Time-Change, which is the time at which the tariff would 895 change again. Either all three or none of these AVPs MUST be present 896 in the QAR. 898 The Resource Authorizing Entity returns a CC-Time AVP ([RFC4006]) in 899 the QAA message which is the total authorized gate-on time for the 900 service. If the QAR included two Tariff-Time-Change AVPs, the 901 current time plus the CC-Time AVP returned in the QAA MUST NOT exceed 902 the second Tariff-Time-Change AVP from the QAR. Based on information 903 in the Cost-Information AVPs, the Resource Authorizing Entity can use 904 the CC-Time AVP to guarantee that the total cost of the session will 905 not exceed a certain threshold, which allows, for example, support of 906 prepaid users. 908 Each ACR message contains a triplet of QoS-Authorization-Resources 909 AVP, Cost-Information AVP, and CC-Time AVP. This represents the 910 total time consumed at the given cost for the given resources. Note 911 that an ACR message MUST be sent separately for each interval defined 912 by the Tariff-Time-Change AVPs and the expiration of the CC-Time 913 returned in the QAA (Figure 6). 915 The Network Element starts an accounting session by sending an 916 Accounting-Request message (ACR) after successful QoS reservation and 917 activation of the data flow (Figure 5). After every successful re- 918 authorization procedure the Network element MUST initiate an interim 919 accounting message exchange (Figure 6). After successful session 920 termination the Network element MUST initiate a final exchange of 921 accounting messages for terminating of the accounting session and 922 reporting final records for the usage of reserved QoS resources 923 (Figure 8). 925 6. Diameter QoS authorization application Messages 927 The Diameter QoS Application requires the definition of new mandatory 928 AVPs and Command-codes [RFC3588]. Four new Diameter messages are 929 defined along with Command-Codes whose values MUST be supported by 930 all Diameter implementations that conform to this specification. 932 Command-Name Abbrev. Code Reference 933 QoS-Authz-Request QAR [TBD] Section 6.1 934 QoS-Authz-Answer QAA [TBD] Section 6.2 935 QoS-Install-Request QIR [TBD] Section 6.3 936 QoS-Install-Answer QIA [TBD] Section 6.4 938 In addition, the following Diameter Base protocol messages are used 939 in the Diameter QoS application: 941 Command-Name Abbrev. Code Reference 942 Accounting-Request ACR 271 RFC 3588 943 Accounting-Request ACR 271 RFC 3588 944 Accounting-Answer ACA 271 RFC 3588 945 Re-Auth-Request RAR 258 RFC 3588 946 Re-Auth-Answer RAA 258 RFC 3588 947 Abort-Session-Request ASR 274 RFC 3588 948 Abort-Session-Answer ACA 274 RFC 3588 949 Session-Term-Request STR 275 RFC 3588 950 Session-Term-Answer STA 275 RFC 3588 952 Diameter nodes conforming to this specification MAY advertise support 953 by including the value of TBD (TBD) in the Auth-Application-Id or the 954 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 955 Capabilities-Exchange-Answer commands [RFC3588]. 957 The value of TBD (TBD) MUST be used as the Application-Id in all QAR/ 958 QAA and QIR/QIA commands. 960 The value of TBD (TBD) MUST be used as the Application-Id in all ACR/ 961 ACA commands, because this application defines new, mandatory AVPs 962 for accounting. 964 The value of zero (0) SHOULD be used as the Application-Id in all 965 STR/STA, ASR/ASA, and RAR/RAA commands, because these commands are 966 defined in the Diameter base protocol and no additional mandatory 967 AVPs for those commands are defined in this document. 969 6.1. QoS-Authorization Request (QAR) 971 The QoS-Authorization-Request message (QAR) indicated by the Command- 972 Code field set to TDB (TBD) and 'R' bit set in the Command Flags 973 field is used by Network elements to request quality of service 974 related resource authorization for a given flow. 976 The QAR message MUST carry information for signaling session 977 identification, Authorizing Entity identification, information about 978 the requested QoS, and the identity of the QoS requesting entity. In 979 addition, depending on the deployment scenario, an authorization 980 token and credentials of the QoS requesting entity SHOULD be 981 included. 983 The message format is defined as follows: 985 ::= < Diameter Header: XXX, REQ, PXY > 986 < Session-Id > 987 { Auth-Application-Id } 988 { Origin-Host } 989 { Origin-Realm } 990 { Destination-Realm } 991 { Auth-Request-Type } 992 [ Destination-Host ] 993 [ User-Name ] 994 * [ QoS-Authorization-Resources ] 995 [ QoS-Authentication-Data ] 996 [ Cost-Information ] 997 [ Acc-Multisession-Id ] 998 [ Bound-Auth-Session-Id ] 999 * [ AVP ] 1001 6.2. QoS-Authorization Answer (QAA) 1003 The QoS-Authorization-Answer message (QAA), indicated by the Command- 1004 Code field set to TBD (TBD) and 'R' bit cleared in the Command Flags 1005 field is sent in response to the QoS-Authorization-Request message 1006 (QAR). If the QoS authorization request is successfully authorized, 1007 the response will include the AVPs to allow authorization of the QoS 1008 resources as well as accounting and transport plane gating 1009 information. 1011 The message format is defined as follows: 1013 ::= < Diameter Header: XXX, PXY > 1014 < Session-Id > 1015 { Auth-Application-Id } 1016 { Auth-Request-Type } 1017 { Result-Code } 1018 { Origin-Host } 1019 { Origin-Realm } 1020 * [ QoS-Authorization-Resources ] 1021 [ CC-Time ] 1022 [ Acc-Multisession-Id ] 1023 [ Session-Timeout ] 1024 [ Authz-Session-Lifetime ] 1025 [ Authz-Grace-Period ] 1026 * [ AVP ] 1028 6.3. QoS-Install Request (QIR) 1030 The QoS-Install Request message (QIR), indicated by the Command-Code 1031 field set to TDB (TBD) and 'R' bit set in the Command Flags field is 1032 used by Authorizing entity to install or update the QoS parameters 1033 and the flow state of an authorized flow at the transport plane 1034 element. 1036 The message MUST carry information for signaling session 1037 identification or identification of the flow to which the provided 1038 QoS rules apply, identity of the transport plane element, description 1039 of provided QoS parameters, flow state and duration of the provided 1040 authorization. 1042 The message format is defined as follows: 1044 ::= < Diameter Header: XXX, REQ, PXY > 1045 < Session-Id > 1046 { Auth-Application-Id } 1047 { Origin-Host } 1048 { Origin-Realm } 1049 { Destination-Realm } 1050 { Auth-Request-Type } 1051 [ Destination-Host ] 1052 * [ QoS-Authorization-Resources ] 1053 [ Session-Timeout ] 1054 [ Authz-Session-Lifetime ] 1055 [ Authz-Grace-Period ] 1056 [ Authz-Session-Volume ] 1057 * [ AVP ] 1059 6.4. QoS-Install Answer (QAA) 1061 The QoS-Install Answer message (QAA), indicated by the Command-Code 1062 field set to TBD (TBD) and 'R' bit cleared in the Command Flags field 1063 is sent in response to the QoS-Install Request message (QIR) for 1064 confirmation of the result of the installation of the provided QoS 1065 reservation instructions. 1067 The message format is defined as follows: 1069 ::= < Diameter Header: XXX, PXY > 1070 < Session-Id > 1071 { Auth-Application-Id } 1072 { Origin-Host } 1073 { Origin-Realm } 1074 { Result-Code } 1075 * [ QoS-Authorization-Resources ] 1076 * [ AVP ] 1078 6.5. Accounting Request (ACR) 1080 The Accounting Request message (ACR), indicated by the Command-Code 1081 field set to 271 and 'R' bit set in the Command Flags field is used 1082 by Network Element to report parameters of the authorized and 1083 established QoS reservation. 1085 The message MUST carry accounting information authorized QoS 1086 resources and its usage, e.g., QoS-Authorized-Resources, CC-Time, CC- 1087 Cost, Acc-Multi-Session-Id. 1089 The message format is defined as follows: 1091 ::= < Diameter Header: XXX, REQ, PXY > 1092 < Session-Id > 1093 { Acct-Application-Id } 1094 { Destination-Realm } 1095 [ Destination-Host ] 1096 [ Accounting-Record-Type ] 1097 [ Accounting-Record-Number ] 1098 * [ QoS-Authorization-Resources ] 1099 [ Cost-Information ] 1100 [ CC-Time ] 1101 [ Acc-Multi-Session-Id ] 1102 * [ AVP ] 1104 6.6. Accounting Answer (ACA) 1106 The Accounting Answer message (ACA), indicated by the Command-Code 1107 field set to 271 and 'R' bit cleared in the Command Flags field is 1108 sent in response to the Accounting Request message (ACR) as an 1109 acknowledgment of the ACR message and MAY carry additional management 1110 information for the accounting session, e.g. Acc-Interim-Interval 1111 AVP. 1113 The message format is defined as follows: 1115 ::= < Diameter Header: XXX, PXY > 1116 < Session-Id > 1117 { Acct-Application-Id } 1118 [ Result-Code ] 1119 [ Accounting-Record-Type ] 1120 [ Accounting-Record-Number ] 1121 [ Acc-Multi-Session-Id ] 1122 * [ AVP ] 1124 7. Diameter QoS Authorization Application AVPs 1126 Each of the AVPs identified in the QoS-Authorization-Request/Answer 1127 and QoS-Install-Request/Answer messages and the assignment of their 1128 value(s) is given in this section. 1130 7.1. Diameter Base Protocol AVPs 1132 The Diameter QoS application uses a number of session management 1133 AVPs, defined in the Base Protocol ([RFC3588]). 1135 Attribute Name AVP Code Reference [RFC3588] 1136 Origin-Host 264 Section 6.3 1137 Origin-Realm 296 Section 6.4 1138 Destination-Host 293 Section 6.5 1139 Destination-Realm 283 Section 6.6 1140 Auth-Application-Id 258 Section 6.8 1141 Result-Code 268 Section 7.1 1142 Auth-Request-Type 274 Section 8.7 1143 Session-Id 263 Section 8.8 1144 Authz-Lifetime 291 Section 8.9 1145 Authz-Grace-Period 276 Section 8.10 1146 Session-Timeout 27 Section 8.13 1147 User-Name 1 Section 8.14 1148 QoS-Filter-Rule 407 Section 6.9 [RFC4005] 1150 Some of the listed AVPs require definition and assignment of 1151 additional values which is described here: 1153 Auth-Application-Id AVP 1155 The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to 1156 Diameter applications. The value of the Auth-Application-Id for 1157 the Diameter QoS application is TBD (TBD). 1159 7.2. Credit Control application AVPs 1161 The Diameter QoS application provides accounting for usage of 1162 reserved QoS resources. Diameter QoS accounting has built-in support 1163 for online, duration based accounting. For this purpose it re-uses a 1164 number of AVPs defined in Diameter Credit Control application. 1165 [RFC4006]. 1167 Attribute Name AVP Code Reference [RFC4006] 1168 Cost-Information AVP 423 Section 8.7 1169 Unit-Value AVP 445 Section 8.8 1170 Currency-Code AVP 425 Section 8.11 1171 Cost-Unit AVP 424 Section 8.12 1172 CC-Time AVP 420 Section 8.21 1173 Tariff-Time-Change AVP 451 Section 6.20 1175 Usage of the listed AVPs is described in Section 5 1177 7.3. Accounting AVPs 1179 The Diameter QoS application uses Diameter Accounting and accounting 1180 AVPs as defined in Section 9 of [RFC3588]. Additional description of 1181 the usage of some of them in QoS authorization context is provided: 1183 Attribute Name AVP Code Reference [RFC3588] 1184 Acct-Application-Id 259 Section 6.9 1185 Accounting-Record-Type 480 Section 9.8.1 1186 Accounting-Interim-Interval 85 Section 9.8.2 1187 Accounting-Record-Number 485 Section 9.8.3 1188 Accounting-Realtime-Required 483 Section 9.8.7 1189 Acc-Multi-Session-ID 50 Section 9.8.5 1191 The following AVP needs further explanation: 1193 Acct-Application-Id AVP 1195 The Acct-Application-Id AVP (AVP Code 259)is assigned by IANA to 1196 Diameter applications. The value of the Acct-Application-Id for 1197 the Diameter QoS application is TBD (TBD). 1199 Acc-Multisession-ID 1201 Acc-Multi-Session-ID AVP (AVP Code 50) SHOULD be used to link 1202 multiple accounting sessions together, allowing the correlation of 1203 accounting information. This AVP MAY be returned by the Diameter 1204 server in a QoS-Authorization-Answer message (QAA), and MUST be 1205 used in all accounting messages for the given session. 1207 7.4. Diameter QoS Application Defined AVPs 1209 This section defines the Quality of Service AVPs that are specific to 1210 the Diameter QoS application and MAY be included in the Diameter QoS 1211 application messages. Unlike the approach followed with RSVP (see 1212 [RFC2749]), where the entire RSVP message is encapsulated into a COPS 1213 message, only the relevant fields SHOULD be included. This approach 1214 avoids a certain overhead of transmitting fields which are irrelevant 1215 for the AAA infrastructure. It keeps implementations simpler and it 1216 allows the reuse of other Diameter AVPs. 1218 The following table describes the Diameter AVPs in the QoS 1219 Application, their AVP code values, types, possible flag values, and 1220 whether the AVP MAY be encrypted. 1222 | AVP Flag rules | 1223 |----+---+----+-----|----+ 1224 AVP Section | | |SHLD| MUST| | 1225 Attribute Name Code Defined Data Type |MUST|MAY| NOT| NOT|Encr| 1226 ------------------------------------------+----+---+----+-----+----+ 1227 Signaling-Session TBD 7.4 Unsigned32 | M | P | | V | Y | 1228 -Id | | | | | | 1229 Flow-ID TBD 7.4 Unsigned32 | M | P | | V | Y | 1230 SPI TBD 7.4 Unsigned32 | M | P | | V | Y | 1231 QoS-Flow-State TBD 7.4 Enumerated | M | P | | V | Y | 1232 IND-Flow TBD 7.4 Grouped | M | P | | V | Y | 1233 Flows TBD 7.4 Grouped | M | P | | V | Y | 1234 QSPEC TBD 7.4 OctetString| M | P | | V | Y | 1235 QoS-Auth TBD 7.4 Grouped | M | P | | V | Y | 1236 -Resources | | | | | | 1237 QoS-Auth-Data TBD 7.4 Grouped | M | P | | V | Y | 1238 Bound-Auth | | | | | | 1239 -Session-Id TBD 7.4 UTF8String | M | P | | V | Y | 1240 ------------------------------------------+----+---+----+-----+----+ 1242 Signaling-Session-ID 1244 Signaling-Session-ID AVP (AVP Code TBD) is of type Unsigned32 and 1245 contains a copy of the QoS signaling session identifier, which is 1246 a unique identifier of the QoS signaling session that in NSIS case 1247 remains unchanged for the duration of the session. 1249 Flow-ID 1251 The Flow-ID AVP (AVP Code TBD) is of type Unsigned32 and contains 1252 identifier of an IP flow. 1254 SPI 1256 The SPI AVP (AVP Code TBD) is of type Unsigned32 and extends the 1257 QoS-Filter-Rule AVP to support IPsec protected traffic. 1259 QoS-Flow-State 1261 The QoS-Flow-State AVP (AVP Code TBD) is of type Enumerated. It 1262 gives an indication by the Authorizing entity how the flow MUST be 1263 treated. When included in a QAA message, it is instructions to 1264 the QoS network element with regard to the state to which the flow 1265 should be set. The supported values are: 1267 0 Open - Enable the transport plane service, for which 1268 the signaling is done 1269 1 Close - Disable the transport plane service 1270 2 Maintain - Current state (enabled/disabled) of the transport 1271 plane service is maintained 1273 The QoS-Flow-State is an optional AVP. When not included in a QAA 1274 response, the default behaviour is to immediately allow the flow 1275 of packets (Open). 1277 IND-Flows 1279 The IND-Flows AVP (AVP Code TBD) is of type Grouped and specifies 1280 IP Flows via their flow identifiers and filter-rule. 1282 IND-Flows ::= 1283 [Flow-Id] 1284 [QoS-Filter-Rule] 1285 [0-1] [SPI] 1286 [0-1] [QoS-Flow-State] 1288 Flows 1290 The Flows AVP (AVP Code TBD) is of type Grouped and contains all 1291 the individual flows that receive the same QoS specified in the 1292 included QSPEC. 1294 Flows ::= < AVP Header: XXX > 1295 [1+]* [ IND-Flows ] 1297 QSPEC 1299 The QSPEC AVP (AVP Code TBD) is of type OctetString and contains 1300 QoS parameter information. Description format is taken from QoS 1301 NSLP Qspec template, which is expected to cover all present QoS 1302 description methods [I-D.ietf-nsis-qspec]. 1304 QoS-Authorization-Resources 1306 The QoS-Auth-Resources AVP (AVP Code TBD) is of type Grouped and 1307 includes description of the resources that have been requested by 1308 the user or authorized by the application server for a particular 1309 QoS request. More than one MAY be included into a message. 1311 QoS-Auth-Resources ::= < AVP Header: XXX > 1312 [0-1] [ Signaling-Session-ID ] 1313 [0-1]* [ Flows ] 1314 [1] [ QSPEC ] 1315 [0-1] [ QoS-Flow-State ] 1317 Included QoS-Flow-State AVP SHOULD be overwritten by any included 1318 QoS-Flow-State AVPs specified for the individual flows. 1320 QoS-Authentication-Data 1322 The QoS-Authentication-Data AVP (AVP Code TBD) is of type 1323 OctetString. It is a container that carries application session 1324 or user specific data that allows to the Authorizing entity in 1325 computation of the authorization decision. 1327 Bound-Authentication-Session-Id 1329 The Bound-Authentication-Session AVP (AVP Code TBD) is of type 1330 UTF8String. It carries the id of the Diameter authentication 1331 session that is used for the network access authentication (NASREQ 1332 authentication session). It is used to tie the QoS authorization 1333 request to a priory authentication of the end host done by a 1334 collocated NASREQ application at the QoS NE. 1336 8. Examples 1338 This section presents an example of the interaction between the 1339 application layer signaling and the QoS signaling along the data 1340 path. The application layer signaling is, in this example, provided 1341 using SIP. Signaling for a QoS resource reservation is done using 1342 the QoS NSLP. The authorization of the QoS reservation request is 1343 done by the Diameter QoS application (DQA). 1345 End-Host SIP Server Correspondent 1346 requesting QoS (DQA Server) Node 1348 | | | 1349 ..|....Application layer SIP signaling.......|..............|.. 1350 . | Invite (SDP) | | . 1351 . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | . 1352 . | 100 Trying | | . 1353 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| . 1354 . | +-.-.-.....-.-.> . 1355 . | | 180 SDP' | . 1356 . | <-.-.-.....-.-.+ . 1357 . | +--------+--------+ | . 1358 . | |Authorize session| | . 1359 . | | parameters | | . 1360 . | 180 (Session parameters) +--------+--------+ | . 1361 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | . 1362 ..|..........................................|... ..........|.. 1363 | | | 1364 | +------------+ | | 1365 | | NE | | | 1366 | |(DQA Client)| | | 1367 | +------+-----+ | | 1368 | | | | 1369 |QoS NSLP Reserve | | | 1370 +------------------> QAR | | 1371 | (POLICY_DATA>v +- - - - -<>- - - -> | 1372 | QSPEC) v >===>(Destination-Host, | | 1373 | v >=======>QoS-Auth-Data, ++------------+ | 1374 | >===========>QoS-Authz-Resources, |Authorize | | 1375 | |Cost-Info) |QoS resources| | 1376 | | ++------------+ | 1377 | | QAA | | 1378 | <- - - - -<>- - - -+ | 1379 | |(Result-Code, | | 1380 | |QoS-Authz-Resources, | | 1381 | |CC-Time, | | 1382 | |Authz-Lifetime) | | 1383 | +---------+--------+ | | 1384 | |Install QoS state1| | | 1385 | |+ Authz. session | | | 1386 | +---------+--------+ | | 1387 | |QoS NSLP Reserve | 1388 | +---------------..............---------> 1389 | | | 1390 | | QoS NSLP Response| 1391 |QoS NSLP Response <---------------..............---------+ 1392 <------------------+ | 1393 | | QoS NSLP Query| 1394 |QoS NSLP Query <---------------..............---------+ 1395 <------------------+ | 1396 |QoS NSLP Reserve | | 1397 +------------------> QAR | | 1398 | +- - - - -<>- - - -> | 1399 | | +---+---------+ | 1400 | | |Authorize | | 1401 | | |QoS resources| | 1402 | | QAA +---+---------+ | 1403 | <- - - - -<>- - - -+ | 1404 | +---------+--------+ | | 1405 | |Install QoS state2| | 1406 | |+ Authz. session | | 1407 | +---------+--------+ | 1408 | | QoS NSLP Reserve | 1409 | +---------------..............---------> 1410 | | QoS NSLP Response| 1411 |QoS NSLP Response <---------------..............---------+ 1412 <------------------+ | 1413 | | | 1414 /------------------+--Data Flow---------------------------\ 1415 \------------------+--------------------------------------/ 1416 | | | 1418 .-.-.-.-. SIP signaling 1419 --------- QoS NSLP signaling 1420 - - - - - Diameter QoS Application messages 1421 ========= Mapping of objects between QoS and AAA protocol 1423 Figure 26: Example for a token-based QoS authorization 1425 The communication starts with SIP signaling between the two end 1426 points and the SIP server for negotiation and authorization of the 1427 requested service and its parameters (Figure 26). As a part of the 1428 process, the SIP server verifies whether the user at Host A is 1429 authorized to use the requested service (and potentially the ability 1430 to get charged for the service usage). Negotiated session parameters 1431 are provided to the end host. 1433 Subsequently, Host A initiates a QoS signaling message towards Host 1434 B. It sends a QoS NSLP Reserve message, in which it includes 1435 description of the required QoS (QSPEC object) and authorization data 1436 for negotiated service session (part of the POLICY_DATA object). 1437 Authorization data includes, as a minimum, the identity of the 1438 authorizing entity (e.g., the SIP server) and an identifier of the 1439 application service session for which QoS resources are requested. 1441 A QoS NSLP Reserve message is intercepted and processed by the first 1442 QoS aware Network Element. The NE uses the Diameter QoS application 1443 to request authorization for the received QoS reservation request. 1444 The identity of the Authorizing Entity (in our case the SIP server 1445 that is co-located with a Diameter server) is put into the 1446 Destination-Host AVP, any additional session authorization data is 1447 encapsulated into the QoS-Authentication AVP and the description of 1448 the QoS resources is included into QoS-Authorized-Resources AVP. In 1449 addition, the NE rates the requested QoS resources and announces the 1450 charging rate into the Cost-Information AVP. These AVPs are included 1451 into a QoS Authorization Request message, which is sent to the 1452 Authorizing entity. 1454 A Diameter QAR message will be routed through the AAA network to the 1455 Authorizing Entity. The Authorizing Entity verifies the requested 1456 QoS against the QoS resources negotiated for the service session and 1457 replies with QoS-Authorization answer (QAA) message. It carries the 1458 authorization result (Result-Code AVP) and the description of the 1459 authorized QoS parameters (QoS-Authorized-Resources AVP), as well as 1460 duration of the authorization session (Authorization-Lifetime AVP) 1461 and duration of the time (CC-Time) for which the end-user should be 1462 charged with the rate announced in the QAR message. The NE interacts 1463 with the traffic control function and installs the authorized QoS 1464 resources and forwards the QoS NSLP Reserve message further along the 1465 data path. 1467 If the data communication might be necessary in both directions, from 1468 Host A to Host B and vice versa, a separate QoS signaling 1469 communication is required for the reverse direction (with path- 1470 coupled signaling). This message exchange is not shown in this 1471 example. 1473 9. Security Considerations 1475 This document describes a mechanism for performing authorization of a 1476 QoS reservation at a third party entity. Therefore, it is necessary 1477 the QoS signaling application to carry sufficient information that 1478 should be forwarded to the backend AAA server. This functionality is 1479 particularly useful in roaming environments where the authorization 1480 decision is most likely provided at an entity where the user can be 1481 authorized, such as in the home realm. 1483 QoS signaling application MAY re-use the authenticated identities 1484 used for the establishment of the secured transport channel for the 1485 signaling messages, e.g., TLS or IPsec between the end host and the 1486 policy aware QoS NE. In addition, a collocation of the QoS NE with, 1487 for example, the Diameter NASREQ application ([RFC4005]) may allow 1488 the QoS authorization to be based on the authenticated identity used 1489 during the network access authentication protocol run. If a co- 1490 located deployment is not desired then special security protection is 1491 required to ensure that arbitrary nodes cannot reuse a previous 1492 authentication exchange to perform an authorization decision. 1494 Additionally, QoS authorization might be based on the usage of 1495 authorization tokens that are generated by the Authorizing Entity and 1496 provided to the end host via application layer signaling. 1498 The impact of the existence of different authorization models is 1499 (with respect to this Diameter QoS application) the ability to carry 1500 different authentication and authorization information. Further 1501 discussions on the authorization handling for QoS signaling protocols 1502 is available with [I-D.tschofenig-nsis-aaa-issues] and 1503 [I-D.tschofenig-nsis-qos-authz-issues]. 1505 10. Acknowledgements 1507 The authors would like to thank John Loughney and Allison Mankin for 1508 their input to this document. 1510 11. Open Issues 1512 Open issues related to this draft are listed at the issue tracker 1513 available at: http://www.tschofenig.com:8080/diameter-qos/ 1515 12. References 1517 12.1. Normative References 1519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1520 Requirement Levels", BCP 14, RFC 2119, March 1997. 1522 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1523 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1525 12.2. Informative References 1527 [ETSI-OSP] 1528 European Telecommunications Standards Institute, 1529 "Telecommunications and Internet Protocol Harmonization 1530 Over Networks (TIPHON); Open Settlement Protocol (OSP) 1531 for Inter-domain pricing, authorization, and usage 1532 exchange", TS 101 321. 1534 [I-D.ietf-nsis-ntlp] 1535 Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 1536 Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-07 1537 (work in progress), July 2005. 1539 [I-D.ietf-nsis-qos-nslp] 1540 Bosch, S., "NSLP for Quality-of-Service signalling", 1541 draft-ietf-nsis-qos-nslp-07 (work in progress), July 2005. 1543 [I-D.ietf-nsis-qspec] 1544 Ash, J., "QoS-NSLP QSPEC Template", 1545 draft-ietf-nsis-qspec-05 (work in progress), July 2005. 1547 [I-D.ietf-sipping-trait-authz] 1548 Peterson, J., "Trait-based Authorization Requirements for 1549 the Session Initiation Protocol (SIP)", 1550 draft-ietf-sipping-trait-authz-01 (work in progress), 1551 February 2005. 1553 [I-D.tschofenig-nsis-aaa-issues] 1554 Tschofenig, H., "NSIS Authentication, Authorization and 1555 Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 1556 (work in progress), March 2003. 1558 [I-D.tschofenig-nsis-qos-authz-issues] 1559 Tschofenig, H., "QoS NSLP Authorization Issues", 1560 draft-tschofenig-nsis-qos-authz-issues-00 (work in 1561 progress), June 2003. 1563 [I-D.tschofenig-sip-saml] 1564 Tschofenig, H., "Using SAML for SIP", 1565 draft-tschofenig-sip-saml-04 (work in progress), 1566 July 2005. 1568 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 1569 Services", RFC 2210, September 1997. 1571 [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description 1572 Protocol", RFC 2327, April 1998. 1574 [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., 1575 and A. Sastry, "COPS usage for RSVP", RFC 2749, 1576 January 2000. 1578 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 1579 for Policy-based Admission Control", RFC 2753, 1580 January 2000. 1582 [RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP) 1583 Extensions for Media Authorization", RFC 3313, 1584 January 2003. 1586 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 1587 "Session Authorization Policy Element", RFC 3520, 1588 April 2003. 1590 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 1591 Session Set-up with Media Authorization", RFC 3521, 1592 April 2003. 1594 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 1595 "Diameter Network Access Server Application", RFC 4005, 1596 August 2005. 1598 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 1599 Loughney, "Diameter Credit-Control Application", RFC 4006, 1600 August 2005. 1602 [RFC4027] Josefsson, S., "Domain Name System Media Types", RFC 4027, 1603 April 2005. 1605 Authors' Addresses 1607 Frank M. Alfano 1608 Lucent Technologies 1609 1960 Lucent Lane 1610 Naperville, IL 60563 1611 USA 1613 Phone: +1 630 979 7209 1614 Email: falfano@lucent.com 1616 Peter J. McCann 1617 Lucent Technologies 1618 1960 Lucent Lane 1619 Naperville, IL 60563 1620 USA 1622 Phone: +1 630 713 9359 1623 Email: mccap@lucent.com 1625 Hannes Tschofenig 1626 Siemens 1627 Otto-Hahn-Ring 6 1628 Munich, Bavaria 81739 1629 Germany 1631 Email: Hannes.Tschofenig@siemens.com 1632 URI: http://www.tschofenig.com 1634 Tseno Tsenov 1635 Siemens 1636 Otto-Hahn-Ring 6 1637 Munich, Bavaria 81739 1638 Germany 1640 Email: tseno.tsenov@mytum.de 1642 Intellectual Property Statement 1644 The IETF takes no position regarding the validity or scope of any 1645 Intellectual Property Rights or other rights that might be claimed to 1646 pertain to the implementation or use of the technology described in 1647 this document or the extent to which any license under such rights 1648 might or might not be available; nor does it represent that it has 1649 made any independent effort to identify any such rights. Information 1650 on the procedures with respect to rights in RFC documents can be 1651 found in BCP 78 and BCP 79. 1653 Copies of IPR disclosures made to the IETF Secretariat and any 1654 assurances of licenses to be made available, or the result of an 1655 attempt made to obtain a general license or permission for the use of 1656 such proprietary rights by implementers or users of this 1657 specification can be obtained from the IETF on-line IPR repository at 1658 http://www.ietf.org/ipr. 1660 The IETF invites any interested party to bring to its attention any 1661 copyrights, patents or patent applications, or other proprietary 1662 rights that may cover technology that may be required to implement 1663 this standard. Please address the information to the IETF at 1664 ietf-ipr@ietf.org. 1666 Disclaimer of Validity 1668 This document and the information contained herein are provided on an 1669 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1670 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1671 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1672 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1673 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1676 Copyright Statement 1678 Copyright (C) The Internet Society (2005). This document is subject 1679 to the rights, licenses and restrictions contained in BCP 78, and 1680 except as set forth therein, the authors retain all their rights. 1682 Acknowledgment 1684 Funding for the RFC Editor function is currently provided by the 1685 Internet Society.