idnits 2.17.1 draft-ietf-dime-diameter-qos-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 24. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2182. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2206. 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 (January 29, 2008) is 5931 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: 'RFC4282' is mentioned on line 865, but not defined ** Obsolete undefined reference: RFC 4282 (Obsoleted by RFC 7542) == Missing Reference: 'TBD' is mentioned on line 1361, but not defined == Unused Reference: 'RFC4006' is defined on line 2065, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-qos-nslp' is defined on line 2076, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 2080, but no explicit reference was found in the text == Unused Reference: 'RFC2749' is defined on line 2086, but no explicit reference was found in the text == Unused Reference: 'RFC3313' is defined on line 2098, but no explicit reference was found in the text == Unused Reference: 'RFC3521' is defined on line 2106, but no explicit reference was found in the text == Unused Reference: 'RFC4027' is defined on line 2110, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 2113, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-04 == Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-01 ** 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: 6 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Sun, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track P. McCann 5 Expires: August 1, 2008 Motorola Labs 6 H. Tschofenig 7 Nokia Siemens Networks 8 T. Tsou 9 Huawei 10 A. Doria 11 Lulea University of Technology 12 G. Zorn 13 Aruba Networks 14 January 29, 2008 16 Diameter Quality of Service Application 17 draft-ietf-dime-diameter-qos-04.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 August 1, 2008. 44 Copyright Notice 46 Copyright (C) The IETF Trust (2008). 48 Abstract 50 This document describes framework, messages and procedures for the 51 Diameter Quality of Service (QoS) application. The Diameter QoS 52 application allows network elements to interact with Diameter servers 53 when allocating QoS resources in the network. In particular, two 54 modes of operation - Pull and Push are defined. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Network element functional model . . . . . . . . . . . . . 8 62 3.2. Implications of Endpoint QoS Capabilities . . . . . . . . 10 63 3.2.1. Category . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.2.2. Interaction modes between authorizing entity and 65 network element . . . . . . . . . . . . . . . . . . . 10 66 3.3. Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.3.1. Schemes for pull mode . . . . . . . . . . . . . . . . 12 68 3.3.2. Schemes for push mode . . . . . . . . . . . . . . . . 15 69 3.4. QoS Application Requirements . . . . . . . . . . . . . . . 16 70 4. QoS Application Session Establishment and Management . . . . . 21 71 4.1. Parties involved . . . . . . . . . . . . . . . . . . . . . 21 72 4.2. Session Establishment . . . . . . . . . . . . . . . . . . 21 73 4.2.1. Session establishment for pull mode . . . . . . . . . 21 74 4.2.2. Session establishment for push mode . . . . . . . . . 24 75 4.2.3. Discovery and selection of peer Diameter QoS 76 application node . . . . . . . . . . . . . . . . . . . 27 77 4.3. Session re-authorization . . . . . . . . . . . . . . . . . 28 78 4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 28 79 4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 29 80 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 31 81 4.4.1. Client-Side Initiated Session Termination . . . . . . 31 82 4.4.2. Server-Side Initiated Session Termination . . . . . . 32 83 5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 34 84 5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 34 85 5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 35 86 5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 36 87 5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 36 88 5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 37 89 5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 37 90 6. QoS Application State Machine . . . . . . . . . . . . . . . . 39 91 6.1. Supplemented states for push mode . . . . . . . . . . . . 39 92 7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 41 93 7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 41 94 7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 41 96 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 43 97 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 98 9.1. Example call flow for pull mode . . . . . . . . . . . . . 44 99 9.2. Example call flow for push mode . . . . . . . . . . . . . 46 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 101 10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 49 102 10.2. AVP specific values . . . . . . . . . . . . . . . . . . . 49 103 10.3. AVP flags . . . . . . . . . . . . . . . . . . . . . . . . 49 104 10.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 49 105 10.5. Command Codes . . . . . . . . . . . . . . . . . . . . . . 50 106 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 107 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 108 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 109 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 110 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 111 14.2. Informative References . . . . . . . . . . . . . . . . . . 54 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 113 Intellectual Property and Copyright Statements . . . . . . . . . . 58 115 1. Introduction 117 This document describes framework, messages and procedures for the 118 Diameter Quality of Service (QoS) Application. The Diameter QoS 119 Application allows network elements (NEs) to interact with Diameter 120 servers when allocating QoS resources in the network. 122 In particular, two modes of operation are defined. In the first, 123 called "Pull Mode", the network element pro-actively sends a command 124 to the Diameter server for QoS authorization based on some trigger 125 (such as a QoS signaling protocol) that arrives along the data path. 126 In the second, called "Push Mode", the Diameter server pro-actively 127 sends a command to the network element(s) to install QoS 128 authorization state. This could be triggered, for instance, by off- 129 path signaling such as SIP-based (Session Initiation Protocol) call 130 control. 132 A set of command codes pertinent to this QoS application are 133 specified that allows a single Diameter application to support both 134 Pull and Push modes based on the requirements of network 135 technologies, deployment scenarios and end-host's capabilities. In 136 conjunction with parameters defined in [I-D.ietf-dime-qos-attributes] 137 and in [I-D.ietf-dime-qos-parameters], this document depicts basic 138 call flow procedures to establish, modify and terminate a Diameter 139 QoS application session. 141 2. Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 The following terms are used in this document: 149 Diameter QoS Application Server 151 A Diameter QoS application server is a logical Diameter node that 152 supports the protocol interaction for QoS authorization. The 153 Diameter QoS application server resides in the authorizing entity 154 (AE). In the Pull mode, it responds to a Diameter session 155 initiated by a Diameter QoS application client; in the Push mode, 156 it initiates a Diameter session to a Diameter QoS application 157 client triggered by application signaling or local events. 159 Diameter QoS Application Client 161 A Diameter QoS application client is a logical Diameter node that 162 supports the protocol interaction for QoS enforcement. The 163 Diameter QoS client resides in the network element. In the Pull 164 mode, it initiates a Diameter session to the Diameter QoS 165 application server triggered by a QoS signaling or other events; 166 in the Push mode, it responds to a Diameter session initiated by a 167 Diameter QoS server. 169 Resource Requesting Entity 171 A resource requesting entity is a logical entity that supports the 172 protocol interaction for QoS resources. The resource requesting 173 entity resides in the end-host and is able to communicate with 174 peer logical entities in Authorizing Entity or Network element to 175 trigger the QoS authorization process. 177 Application Server 179 An application server is a network entity that exchanges signaling 180 messages with an application endpoint. It may be a source of 181 authorization for QoS-enhanced application flows. For example, a 182 SIP server is one kind of application server. 184 Application Endpoint 186 An application endpoint is an entity in an end user device that 187 exchanges signaling messages with application servers or directly 188 with other application endpoints. Based on the result of this 189 signaling, the endpoint may make a request for QoS from the 190 network. For example, a SIP User Agent is one kind of application 191 endpoint. 193 Authorizing Entity 195 The authorizing entity acts as a Diameter server (and may 196 collocate with a subscriber database) responsible for authorizing 197 QoS requests for a particular application flow or aggregate. It 198 may be a standalone entity or integrated with an application 199 server. This entity corresponds to the Policy Decision Point 200 (PDP) (see [RFC2753]). 202 AAA Cloud 204 An infrastructure of AAA entities (clients, agents, servers) based 205 on a AAA protocol, which provides trusted secure connections 206 between them. It offers authentication, authorization and 207 accounting services to applications in flexible local and roaming 208 scenarios. Diameter [RFC3588] and RADIUS [RFC2865] are both 209 widely deployed AAA protocols. 211 Network Element (NE) 213 QoS aware router that acts as Diameter client that implements the 214 Diameter QoS application in the context of this document. For 215 almost all scenarios this entity triggers the protocol interaction 216 described in this document. This entity corresponds to the Policy 217 Enforcement Point (PEP) (see [RFC2753]). 219 Pull Mode 221 In this mode, the QoS authorization process is invoked by the QoS 222 reservation request received from the endpoint. The Network 223 Element then requests the QoS authorization decision from the 224 Authorizing entity. 226 Push Mode 228 In this mode, the QoS authorization process is invoked by the 229 request from Application Server or local policies in the 230 Authorizing Entity. The Authorizing Entity then installs the QoS 231 authorization decision to the Network Element directly. 233 3. Framework 235 The Diameter QoS application runs between a network element (acting 236 as a Diameter client) and the resource authorizing entity (acting as 237 a Diameter server). A high-level picture of the resulting 238 architecture is shown in Figure 1. 240 +-------+---------+ 241 | Authorizing | 242 | Entity | 243 |(Diameter Server)| 244 +-------+---------+ 245 | 246 | 247 /\-----+-----/\ 248 //// \\\\ 249 || AAA Cloud || 250 | (Diameter application) | 251 || || 252 \\\\ //// 253 \-------+-----/ 254 | 255 +---+--+ +-----+----+ +---+--+ 256 | | | NE | | | Media 257 + NE +===+(Diameter +===+ NE +=============>> 258 | | | Client) | | | Flow 259 +------+ +----------+ +------+ 261 Figure 1: An Architecture supporting QoS-AAA 263 Figure 1 depicts network elements through which media flows need to 264 pass, a cloud of AAA servers, and an authorizing entity. Note that 265 there may be more than one router that needs to interact with the AAA 266 cloud along the path of a given application flow, although the figure 267 only depicts one for clarity. 269 In some deployment scenarios, QoS aware network elements may request 270 authorization through the AAA cloud based on an incoming QoS 271 reservation request. The network element will route the request to a 272 designated authorizing entity. The authorizing entity will return 273 the result of the authorization decision. In other deployment 274 scenarios, the authorization will be initiated upon dynamic 275 application state, so that the request must be authenticated and 276 authorized based on information from one or more application servers. 277 After receiving the authorization request from the application server 278 or the network element, the authorizing entity decides the 279 appropriate mode (i.e. Push or Pull). The Push or Pull mode can be 280 dynamically determined based on the information received from the 281 request of the application server and/or the information (e.g. 282 policy) in the authorizing entity, or statically configured according 283 to operator's demand, or the messages between AE and NE. The 284 Authorizing Entity may identify the access network through the use of 285 some out-of-band signaling, such as SIP, Diameter, which may be sent 286 from the application server to Authorizing Entity, and then select 287 appropriate resource admission and control policies. 289 If defined properly, the interface between the routers and AAA cloud 290 would be identical in both cases. Routers are therefore insulated 291 from the details of particular applications and need not know that 292 application servers are involved at all. Also, the AAA cloud would 293 naturally encompass business relationships such as those between 294 network operators and third-party application providers, enabling 295 flexible intra- or inter-domain authorization, accounting, and 296 settlement. 298 3.1. Network element functional model 300 Figure 2 depicts a logical operational model of resource management 301 in a router. 303 +-------------------------------------------------------+ 304 | DIAMETER Client | 305 | Functionality | 306 | +---------------++-----------------++---------------+ | 307 | | User || QoS Application || Accounting | | 308 | | Authentication|| Client || Client (e.g. | | 309 | | Client || (Authorization ||for QoS Traffic| | 310 | +---------------+| of QoS Requests)|+---------------+ | 311 | +-----------------+ | 312 +-------------------------------------------------------+ 313 ^ 314 v 315 +--------------+ +----------+ 316 |QoS Signaling | | Resource | 317 |Msg Processing|<<<<<>>>>>>>|Management| 318 +--------------+ +----------+ 319 . ^ | * ^ 320 | v . * ^ 321 +-------------+ * ^ 322 |Signaling msg| * ^ 323 | Processing | * V 324 +-------------+ * V 325 | | * V 326 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 327 . . * V 328 | | * ............................. 329 . . * . Traffic Control . 330 | | * . +---------+. 331 . . * . |Admission|. 332 | | * . | Control |. 333 +----------+ +------------+ . +---------+. 334 <-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> 335 | Packet | | Interface | .+----------+ +---------+. 336 ===>|Processing|====| Selection |===.| Packet |====| Packet |.=> 337 | | |(Forwarding)| .|Classifier| Scheduler|. 338 +----------+ +------------+ .+----------+ +---------+. 339 ............................. 340 <.-.-> = signaling flow 341 =====> = data flow (sender --> receiver) 342 <<<>>> = control and configuration operations 343 ****** = routing table manipulation 345 Figure 2: Network element functional model 347 Processing of incoming QoS reservation requests includes three 348 actions: admission control, authorization and resource reservation. 350 The admission control function provides information for available 351 resources and determines whether there are enough resources to 352 fulfill the request. Authorization is performed by the Diameter 353 client function which involves contacting an authorization entity 354 through the AAA cloud shown in Section 3. If both checks are 355 successful, the authorized QoS parameters are set in the packet 356 classifier and the packet scheduler. Note that the parameters passed 357 to the Traffic Control function may be different from requested QoS 358 (depending on the authorization decision). Once the requested 359 resource is granted, the Resource Management function provides 360 accounting information to the Authorizing entity using the Diameter 361 client function. 363 3.2. Implications of Endpoint QoS Capabilities 365 3.2.1. Category 367 The QoS capabilities of endpoints are varied, which can be 368 categorized as follows: 369 o Category 1 endpoint: Has no QoS capability at both application and 370 network levels. This type of endpoint may set up a connection 371 through application signaling, but it is unable to specify any 372 resource/QoS requirements either through application signaling or 373 does not support network signaling at all. 374 o Category 2 endpoint: Only has QoS capability at the application 375 level. This type of endpoint is able to set up a connection 376 through application signaling with certain resource/QoS 377 requirements (e.g., application attributes), but it is unable to 378 specify any network level resource/QoS requirements (e.g., network 379 QoS class) through network signaling e.g., RSVP or NSIS (or does 380 not support network layer signaling at all). 381 o Category 3 endpoint: Has QoS capability at the network level. 382 This type of endpoint may set up a connection through application 383 signaling and translate service characteristics into network 384 resource/QoS requirements (e.g., network QoS class) locally, and 385 request the resources through network signaling, e.g., RSVP or 386 NSIS. 388 3.2.2. Interaction modes between authorizing entity and network element 390 Different QoS mechanisms are employed in packet networks. Those QoS 391 mechanisms can be categorized into two schemes: IntServ and DiffServ. 392 In the IntServ scheme, network signaling (e.g., RSVP, NSIS, or link 393 specific signaling) is commonly used to initiate a request from 394 endpoint for desired QoS resource of media flow. In the DiffServ 395 scheme, the QoS resources are provisioned based on some predefined 396 QoS service classes instead of endpoint initiated per flow based QoS 397 request. 399 It is obvious that the eligible QoS scheme is correlated to the 400 endpoint's capability in the context of QoS authorization. Since 401 category 1 and 2 endpoints cannot initiate the QoS resource requests 402 through the network signaling, the IntServ model is not applicable to 403 them in general. Depending on network technology and operator's 404 demand, a category 3 endpoint may either make use of the network 405 signaling for requesting the resource or not perform the request. 407 The diversity of QoS capabilities of endpoints and QoS schemes of 408 network technology leads to the distinction on the interaction mode 409 between QoS authorization system and underlying network elements. 410 When the IntServ scheme is employed by category 3 endpoint, the 411 authorization process is typically initiated by network element when 412 a trigger such as the network signaling is received from the 413 endpoint. In the DiffServ scheme, since the network element is 414 unable to request the resource authorization on its own initiative, 415 the authorization process is typically triggered upon either the 416 request of application servers or policies defined by the operator. 418 As a consequence, two interaction modes are needed in support of 419 different combinations of QoS schemes and endpoint's QoS 420 capabilities: Push mode and Pull mode. 422 o Push mode: The QoS authorization process is triggered by 423 application servers or local network conditions (e.g., time of day 424 on resource usage and QoS classes), and the authorization 425 decisions are installed by the authorizing entity to the network 426 element on its own initiative without explicit request. In order 427 to support the push mode, the authorizing entity (i.e., Diameter 428 server) should be able to initiate a Diameter authorization 429 session to communicate with the network element (i.e., Diameter 430 client) without any pre-established connection from the network 431 element. 432 o Pull mode: The QoS authorization process is triggered by the 433 network signaling received from end user equipments or by the 434 local event in the network element according to pre-configured 435 policies, and authorization decisions are produced upon the 436 request of the network element. In order to support the pull 437 mode, the network element (i.e., Diameter client) will initiate a 438 Diameter authorization session to communicate with authorizing 439 entity (i.e., Diameter server). 441 For category 1 and 2 endpoints, the Push mode is required, in 442 particular, category 1 endpoint requires network initiated push mode 443 and category 2 endpoint may use both them. For category 3 endpoint, 444 either push mode or pull mode is doable. 446 The Push mode is applicable to certain networks, for example, Cable 447 network, DSL, Ethernet, Diffserv enabled IP/MPLS as defined by other 448 SDOs, e.g., ETSI TISPAN and ITU-T. The Pull mode is more appropriate 449 to IntServ enabled IP networks or certain wireless networks such as 450 GPRS networks as defined by 3GPP/PP2. Some networks, e.g., WiMAX may 451 require both Push and Pull modes. 453 3.3. Schemes 455 3.3.1. Schemes for pull mode 457 Three basic authorization schemes for pull mode exist: one two-party 458 and two three-party schemes. The notation adopted here is in respect 459 to the entity that performs the QoS authorization. The 460 authentication of the QoS requesting entity might be done at the 461 network element as part of the QoS signaling protocol, or by an off- 462 path protocol run (on the application layer or for network access 463 authentication) or the authorizing entity might be contacted with 464 request for authentication and authorization of the QoS requesting 465 entity. From the Diameter QoS application's point of view these 466 schemes differ in type of information that need to be carried. Here 467 we focus on the 'Three party scheme' (see Figure 3) and the 'Token- 468 based three party scheme' (see Figure 4). With the 'two party 469 scheme' the QoS resource requesting entity is authenticated by the 470 Network Element and the authorization decision is made either locally 471 at the Network Element itself or offloaded to a trusted entity (most 472 likely within the same administrative domain). In the former case no 473 Diameter QoS protocol interaction is required. 475 +--------------+ 476 | Entity | 477 | authorizing | <......+ 478 | resource | . 479 | request | . 480 +------------+-+ . 481 --^----------|-- . . 482 ///// | | \\\\\ . 483 // | | \\ . 484 | QoS | QoS AAA | QoS |. 485 | authz| protocol |authz |. 486 | req.| | res. |. 487 \\ | | // . 488 \\\\\ | | ///// . 489 QoS --|----------v-- . . 490 +-------------+ request +-+------------+ . 491 | Entity |----------------->| NE | . 492 | requesting | | performing | . 493 | resource |granted / rejected| QoS | <.....+ 494 | |<-----------------| reservation | financial 495 +-------------+ +--------------+ settlement 497 Figure 3: Three Party Scheme 499 With the 'three party scheme' a QoS reservation request that arrives 500 at the Network Element is forwarded to the Authorizing Entity (e.g., 501 in the user's home network), where the authorization decision is 502 made. A business relationship, such as a roaming agreement, between 503 the visited network and the home network ensures that the visited 504 network is compensated for the resources consumed by the user via the 505 home network. 507 financial settlement 508 ...........................+ 509 Authorization V ------- . 510 Token Request +--------------+ / QoS AAA \ . 511 +-------------->| | / protocol \ . 512 | | Authorizing +--------------+ \ . 513 | | Entity | | | | . 514 | +------+ |<--+----+ | | . 515 | | +--------------+ |QoS | |QoS |. 516 | | |authz| |authz|. 517 | |Authorization |req.+| |res. |. 518 | |Token |Token| | |. 519 | | | | | . | . 520 | | \ | | . / . 521 | | \ | | / . 522 | | QoS request |-----V . . 523 +-------------+ + Authz. Token +--------+-----+ . 524 | Entity |----------------->| NE | . 525 | requesting | | performing | . 526 | resource |granted / rejected| QoS | <....+ 527 | |<-----------------| reservation | 528 +-------------+ +--------------+ 530 Figure 4: Token-based Three Party Scheme 532 The 'Token-based Three Party scheme' is applicable to environments 533 where a previous protocol interaction is used to request 534 authorization tokens to assist the authorization process at the 535 Network Element or the Authorizing Entity. 537 The QoS resource requesting entity may be involved in an application 538 layer protocol interaction, for example using SIP, with the 539 Authorizing Entity. As part of this interaction, authentication and 540 authorization at the application layer might take place. As a result 541 of a successful authorization decision, which might involve the 542 user's home AAA server, an authorization token is generated by the 543 Authorizing Entity (e.g., the SIP proxy and an entity trusted by the 544 SIP proxy) and returned to the end host for inclusion into the QoS 545 signaling protocol. The authorization token will be used by a 546 Network Element that receives the QoS signaling message to authorize 547 the QoS request. Alternatively, the Diameter QoS application will be 548 used to forward the authorization token to the user's home network. 549 The authorization token allows the authorization decision performed 550 at the application layer protocol run to be associated with a 551 corresponding QoS signaling session. Note that the authorization 552 token might either refer to established state concerning the 553 authorization decision or the token might itself carry the authorized 554 parameters (protected by a digital signature or a keyed message 555 digest to prevent tampering). In the latter case the authorization 556 token may contain several pieces of information pertaining to the 557 authorized application session, but at minimum it should contain: 558 o An identifier of the Authorizing Entity (for example, of an 559 application server) that issued the authorization token, 560 o An identifier referring to a specific application protocol session 561 for which the token was issued and 562 o A keyed message digest or digital signature protecting the content 563 of the authorization token. 565 A possible structure for the authorization token and the policy 566 element carrying it are proposed in context of RSVP [RFC3520]. 568 In the scenario mentioned above, where the QoS resource requesting 569 entity is involved in an application layer protocol interaction with 570 the Authorizing entity, it may be worthwhile to consider a token less 571 binding mechanism also. The application layer protocol interaction 572 may have indicated the transport port numbers at the QoS resource 573 requesting entity where it might receive media streams, for example 574 in SIP/SDP signalling these port numbers are advertised. The QoS 575 resource requesting entity may also use these port numbers in some IP 576 filter indications to the NE performing QoS reservation so that it 577 may properly tunnel the inbound packets. The NE performing QoS 578 reservation will forward the QoS resource requesting entity's IP 579 address and the IP filter indications to the Authorizing entity in 580 the QoS authz. request. The Authorizing entity will use the QoS 581 resource requesting entity's IP address and the port numbers in the 582 IP filter indication, which will match the port numbers advertised in 583 the earlier application layer protocol interaction, to identify the 584 right piece of policy information to be sent to the NE performing the 585 QoS reservation in the QoS authz. response. 587 3.3.2. Schemes for push mode 589 The push mode can be further divided into two types: endpoint 590 initiated and network initiated. In the former case, the 591 authorization process is triggered by application server upon 592 explicit QoS request from endpoints through application signaling, 593 e.g. SIP; in the latter case, the authorization process is triggered 594 by application server without explicit QoS request from endpoint. 596 In the endpoint initiated scheme, the QoS resource requesting entity 597 (i.e. endpoint) determines the required application level QoS and 598 sends the QoS request through application signaling message, the 599 Application Server will extract application level QoS information and 600 trigger the authorization process to Authorizing entity. In the 601 network initiated scheme, the Authorizing entity and/or Application 602 server should derive and determine the QoS requirement according to 603 application attribute, subscription and endpoint's capability when 604 the endpoint does not explicitly indicate the QoS attributes. The 605 authorizing entity makes authorization decision based on application 606 level QoS information, network policies, end user subscription and 607 network resource availability etc., and installs the decision to 608 network element directly. 610 financial settlement 611 ...........................+ 612 Application V ------- . 613 signaling msg +--------------+ / QoS AAA \ . 614 +-------------->| | / protocol \ . 615 | | Authorizing +--------------+ \ . 616 | | Entity | | | | . 617 | + |<--+----+ | | . 618 | +--------------+ |QoS | |QoS |. 619 | install| |install 620 | |rsp. | |req. |. 621 | | | | |. 622 | | | | . | . 623 | \ | | . / . 624 | \ | | / . 625 V |-----V . . 626 +-------------+ +--------+-----+ . 627 | Entity | | NE | . 628 | requesting | | performing | . 629 | resource |QoS rsrc granted | QoS | <....+ 630 | |<-----------------| reservation | 631 +-------------+ +--------------+ 633 Figure 5: Scheme for Push Mode 635 3.4. QoS Application Requirements 637 A QoS application must meet a number of requirements applicable to a 638 diverse set of networking environments and services. It should be 639 compliant with different deployment scenarios with specific QoS 640 signaling models and security issues. Satisfying the requirements 641 listed below while interworking with QoS signaling protocols, a 642 Diameter QoS application should accommodate the capabilities of the 643 QoS signaling protocols rather than introducing functional 644 requirements on them. A list of requirements for a QoS authorization 645 application is provided here: 647 Inter-domain support 649 In particular, users may roam outside their home network, leading 650 to a situation where the network element and authorizing entity 651 are in different administrative domains. 653 Identity-based Routing 655 The QoS AAA protocol MUST route AAA requests to the Authorizing 656 Entity, based on the provided identity of the QoS requesting 657 entity or the identity of the Authorizing entity encoded in the 658 provided authorization token. 660 Flexible Authentication Support 662 The QoS AAA protocol MUST support a variety of different 663 authentication protocols for verification of authentication 664 information present in QoS signaling messages. The support for 665 these protocols MAY be provided indirectly by tying the signaling 666 communication for QoS to a previous authentication protocol 667 exchange (e.g., using network access authentication). 669 Making an Authorization Decision 671 The QoS AAA protocol MUST exchange sufficient information between 672 the authorizing entity and the enforcing entity (and vice versa) 673 to compute an authorization decision and to execute this decision. 675 Triggering an Authorization Process 677 The QoS AAA protocol MUST allow periodic and event triggered 678 execution of the authorization process, originated at the 679 enforcing entity or even at the authorizing entity. 681 Associating QoS Reservations and Application State 683 The QoS AAA protocol MUST carry information sufficient for an 684 application server to identify the appropriate application session 685 and associate it with a particular QoS reservation. 687 Dynamic Authorization 689 It MUST be possible for the QoS AAA protocol to push updates 690 towards the network element(s) from authorizing entities. 692 Bearer Gating 694 The QoS AAA protocol MUST allow the authorizing entity to gate 695 (i.e., enable/disable) authorized application flows based on, 696 e.g., application state transitions. 698 Accounting Records 700 The QoS AAA protocol may define QoS accounting records containing 701 duration, volume (byte count) usage information and description of 702 the QoS attributes (e.g., bandwidth, delay, loss rate) that were 703 supported for the flow. 705 Sending Accounting Records 707 The network element SHOULD be able to send accounting records for 708 a particular QoS reservation state to an accounting entity. 710 Failure Notification 712 The QoS AAA protocol MUST allow the network element to report 713 failures, such as loss of connectivity due to movement of a mobile 714 node or other reasons for packet loss, to the authorizing entity. 716 Accounting Correlation 718 The QoS AAA protocol may support the exchange of sufficient 719 information to allow for correlation between accounting records 720 generated by the network elements and accounting records generated 721 by an application server. 723 Interaction with other AAA Applications 725 Interaction with other AAA applications such as Diameter Network 726 Access (NASREQ) application [RFC4005] is required for exchange of 727 authorization, authentication and accounting information. 729 In deployment scenarios, where authentication of the QoS reservation 730 requesting entity (e.g., the user) is done by means outside the 731 Diameter QoS application protocol interaction the Authorizing Entity 732 is contacted only with a request for QoS authorization. 733 Authentication might have taken place already via the interaction 734 with the Diameter NASREQ application or as part of the QoS signaling 735 protocol (e.g., Transport Layer Security (TLS) handshake in the 736 General Internet Signaling Transport (GIST) protocol, see 737 [I-D.ietf-nsis-ntlp]). 739 Authentication of the QoS reservation requesting entity to the 740 Authorizing Entity is necessary if a particular Diameter QoS 741 application protocol run cannot be related (or if there is no 742 intention to relate it) to a prior authentication. In this case the 743 Authorizing Entity MUST authenticate the QoS reservation requesting 744 entity in order to authorize the QoS request as part of the Diameter 745 QoS protocol interaction. 747 The document refers to three types of sessions that need to be 748 properly correlated. 750 QoS signaling session 752 The time period during which a QoS signaling protocol establishes, 753 maintains and deletes a QoS reservation state at the QoS network 754 element is referred as QoS signaling session. Different QoS 755 signaling protocols use different ways to identify QoS signaling 756 sessions. The same applies to different usage environments. 757 Currently, this document supports three types of QoS session 758 identifiers, namely a signaling session id (e.g., the Session 759 Identifier used by the NSIS protocol suite), a flow id (e.g., 760 identifier assigned by an application to a certain flow as used in 761 the 3GPP) and a flow description based on the IP parameters of the 762 flow's end points. 764 Diameter authorization session 766 The time period, for which a Diameter server authorizes a 767 requested service (i.e., QoS resource reservation) is referred to 768 as a Diameter authorization session. It is identified by a 769 Session-Id included in all Diameter messages used for management 770 of the authorized service (initial authorization, re- 771 authorization, termination), see [RFC3588]. 773 Application layer session 775 The application layer session identifies the duration of an 776 application layer service which requires provision of certain QoS. 777 An application layer session identifier is provided by the QoS 778 requesting entity in the QoS signaling messages, for example as 779 part of the authorization token. In general, the application 780 session identifier is opaque to the QoS aware network elements. 781 It is included in the authorization request message sent to the 782 Authorizing entity and helps it to correlate the QoS authorization 783 request to the application session state information. 785 Correlating these sessions is done at each of the three involved 786 entities: The QoS requesting entity correlates the application with 787 the QoS signaling sessions. The QoS network element correlates the 788 QoS signaling session with the Diameter authorization sessions. The 789 Authorizing entity SHOULD bind the information about the three 790 sessions together. Note that in certain scenarios not all of the 791 sessions are present. For example, the application session might not 792 be visible to QoS signaling protocol directly if there is no binding 793 between the application session and the QoS requesting entity using 794 the QoS signaling protocol. 796 4. QoS Application Session Establishment and Management 798 4.1. Parties involved 800 Authorization models supported by this application include three 801 parties: 802 o Resource requesting entity 803 o Network Elements (Diameter QoS application (DQA) client) 804 o Authorizing Entity (Diameter QoS application (DQA) server) 806 Note that the QoS resource requesting entity is only indirectly 807 involved in the message exchange. This entity provides the trigger 808 to initiate the Diameter QoS protocol interaction by transmitting QoS 809 signaling messages. The Diameter QoS application is only executed 810 between the Network Element (i.e., DQA client) and the Authorizing 811 Entity (i.e., DQA server). 813 The QoS resource requesting entity may communicate with the 814 Authorizing Entity using application layer signaling for negotiation 815 of service parameters. As part of this application layer protocol 816 interaction, for example using SIP, authentication and authorization 817 might take place. This message exchange is, however, outside the 818 scope of this document. The protocol communication between the QoS 819 resource requesting entity and the QoS Network Element might be 820 accomplished using the NSIS protocol suite, RSVP or a link layer 821 signaling protocol. A description of these protocols is also outside 822 the scope of this document and a tight coupling with these protocols 823 is not desirable since this applications aims to be generic. 825 4.2. Session Establishment 827 The Pull and Push modes use a different set of command codes for 828 session establishment. For other operations, such as session 829 modification and termination, they use the same set of command codes. 831 The Pull mode or Push mode operation is invoked based on the trigger 832 of QoS Authorization session. When a QAR with a new session ID is 833 received, the Authorizing Entity operates in the pull mode; when 834 other triggers are received, the Authorizing Entity operates in the 835 push mode. Similarly, when a QIR with new session ID is received, 836 the Network Element operates in the push mode; when other triggers 837 are received, the Network Element operation in the pull mode. 839 4.2.1. Session establishment for pull mode 841 A request for a QoS reservation or local events received by a Network 842 Element can trigger the initiation of a Diameter QoS authorization 843 session. The Network Element generates a QoS-Authorization-Request 844 (QAR) message in which it maps required objects from the QoS 845 signaling message to Diameter payload objects. 847 Figure 7 shows the protocol interaction between a resource requesting 848 entity, a Network Element and the Authorizing Entity. 850 The Authorizing Entity's identity, information about the application 851 session and/or identity and credentials of the QoS resource 852 requesting entity, requested QoS parameters, signaling session 853 identifier and/or QoS enabled data flows identifiers MAY be 854 encapsulated into respective Diameter AVPs and included into the 855 Diameter message sent to the Authorizing Entity. The QAR is sent to 856 a Diameter server that can either be the home server of the QoS 857 requesting entity or an application server. 859 +----------------------------------+-------------------------------+ 860 | QoS specific Input Data | Diameter QoS AVPs | 861 +----------------------------------+-------------------------------+ 862 | Authorizing entity ID (e.g., | Destination-Host | 863 | taken from authorization token | Destination-Realm | 864 | or derived based on Network | | 865 | Access ID (NAI) [RFC4282] | | 866 | of the QoS requesting entity) | | 867 +----------------------------------+-------------------------------+ 868 | Authorization Token | QoS-Authz-Data | 869 | Credentials of | User-Name | 870 | the QoS requesting entity | | 871 +----------------------------------+-------------------------------+ 872 | QoS parameters | QoS-Resources | 873 +----------------------------------+-------------------------------+ 875 Authorization processing starts at the Diameter QoS server when it 876 receives the QAR. Based on the information in the QoS- 877 Authentication-Data, User-Name and QoS-Resources AVPs the server 878 determines the authorized QoS resources and flow state (enabled/ 879 disabled) from locally available information (e.g., policy 880 information that may be previously established as part of an 881 application layer signaling exchange, or the user's subscription 882 profile). The QoS-Resources AVP is defined in 883 [I-D.ietf-dime-qos-attributes]. The authorization decision is then 884 reflected in the response returned to the Diameter client with the 885 QoS-Authorization-Answer message (QAA). 887 Authorizing 888 End-Host Network Element Entity 889 requesting QoS ( Diameter ( Diameter 890 QoS Client) QoS Server) 891 | | | 892 +---QoS-Reserve---->| | 893 | +- - - - - QAR - - - - - >| 894 | |(QoS-Resources, | 895 | | QoS-Auth-Data,User-ID)| 896 | | +--------+--------------+ 897 | | | Authorize request | 898 | | | Keep session data | 899 | | |/Authz-time,Session-Id/| 900 | | +--------+--------------+ 901 | |< - - - - QAA - - - - - -+ 902 | |(Result-Code, | 903 | |QoS-Resources,Authz-time)| 904 | +-------+---------+ 905 | |Install QoS state| 906 | | + | 907 | | Authz. session | 908 | | /Authz-time/ | QoS Responder 909 | | | Node 910 | +-------+---------+ | 911 | +----------QoS-Reserve---....--->| 912 | | | 913 | |<---------QoS-Response--....----| 914 |<--QoS-Response----+ | 915 | | | 916 |=====================Data Flow==============....===>| 917 | | 918 | +- - - - - QAR - - - - - >| 919 | |(START,QoS-Resources) | 920 | | | 921 | | +--------+--------------+ 922 | | | Report for successful | 923 | | | QoS reservation | 924 | | |Update of reserved QoS | 925 | | | resources | 926 | | +--------+--------------+ 927 | |< - - - - QAA - - - - - -+ 928 | | | 930 Figure 7: Initial QoS Request Authorization for pull 932 The Authorizing Entity keeps authorization session state and SHOULD 933 save additional information for management of the session (e.g., 934 Signaling-Session-Id, authentication data) as part of the session 935 state information. 937 The final result of the authorization request is provided in the 938 Result-Code AVP of the QAA message sent by the Authorizing Entity. 939 In case of successful authorization (i.e., Result-Code = 940 DIAMETER_LIMITED_SUCCESS, (see Section 7.1)), information about the 941 authorized QoS resources and the status of the authorized flow 942 (enabled/disabled) is provided in the QoS-Resources AVP of the QAA 943 message. The QoS information provided via the QAA is installed by 944 the QoS Traffic Control function of the Network Element. The value 945 DIAMETER_LIMITED_SUCCESS indicates that the Authorizing entity 946 expects confirmation via another QAR message for successful QoS 947 resource reservation and for final reserved QoS resources (see 948 below). 950 One important piece of information returned from the Authorizing 951 Entity is the authorization lifetime (carried inside the QAA). The 952 authorization lifetime allows the Network Element to determine how 953 long the authorization decision is valid for this particular QoS 954 reservation. A number of factors may influence the authorized 955 session duration, such as the user's subscription plan or currently 956 available credits at the user's account (see Section 8). The 957 authorization duration is time-based as specified in [RFC3588]. For 958 an extension of the authorization period, a new QoS-Authorization- 959 Request/Answer message exchange SHOULD be initiated. Further aspects 960 of QoS authorization session maintenance is discussed in Section 4.3, 961 Section 4.4 and Section 8. 963 The indication of a successful QoS reservation and activation of the 964 data flow is provided by the transmission of an QAR message, which 965 reports the parameters of the established QoS state: reserved 966 resources, duration of the reservation, and identification of the QoS 967 enabled flow/QoS signaling session. The Diameter QoS server 968 acknowledges the reserved QoS resources with the QA Answer (QAA) 969 message where the Result-Code is set to 'DIAMETER_SUCCESS'. Note 970 that the reserved QoS resources reported in this QAR message MAY be 971 different than those authorized with the initial QAA message, due to 972 the QoS signaling specific behavior (e.g., receiver-initiated 973 reservations with One-Path-With-Advertisements) or specific process 974 of QoS negotiation along the data path. 976 4.2.2. Session establishment for push mode 978 The Diameter QoS server in the Authorizing Entity initiates a 979 Diameter QoS authorization session upon the request for QoS 980 reservation triggered by application layer signaling or by local 981 events, and generates a QoS-Install-Request (QIR) message to Diameter 982 QoS client in the NE in which it maps required objects to Diameter 983 payload objects. 985 Figure 9 shows the protocol interaction between the Authorizing 986 Entity, a Network Element and a resource requesting entity. 988 The Network Element's identity, information about the application 989 session and/or identity and credentials of the QoS resource 990 requesting entity, requested QoS parameters, signaling session 991 identifier and/or QoS enabled data flows identifiers MAY be 992 encapsulated into respective Diameter AVPs and included into the 993 Diameter message sent from a Diameter QoS server in the Authorizing 994 Entity to a Diameter QoS client in the NE. This requires that the 995 Authorizing Entity has knowledge of specific information for 996 allocating and identifying the Network Element that should be 997 contacted and the data flow for which the QoS reservation should be 998 established. This information can be statically configured or 999 dynamically discovered, see Section 3.2.3 for details. 1001 +----------------------------------+-------------------------------+ 1002 | QoS specific Input Data | Diameter QoS AVPs | 1003 +----------------------------------+-------------------------------+ 1004 | Network Element ID (e.g., from | Destination-Host | 1005 | static configuration | Destination-Realm | 1006 | or dynamically discovered, see | | 1007 | Section 3.2.3 for details) | | 1008 +----------------------------------+-------------------------------+ 1009 | Authorization Token | QoS-Authz-Data | 1010 | Credentials of | User-Name | 1011 | the QoS requesting entity | | 1012 +----------------------------------+-------------------------------+ 1013 | QoS parameters | QoS-Resources | 1014 +----------------------------------+-------------------------------+ 1016 Authorization processing starts at the Diameter QoS server when it 1017 receives the request from a resource requesting entity through 1018 application server (e.g., SIP Invite) or the trigger by local events 1019 (e.g., pre-configured timer). Based on the received information the 1020 server determines the authorized QoS resources and flow state 1021 (enabled/disabled) from locally available information (e.g., policy 1022 information that may be previously established as part of an 1023 application layer signaling exchange, or the user's subscription 1024 profile). The authorization decision is then reflected in the QoS- 1025 Install-Request message (QIR) to the Diameter QoS client. 1027 Authorizing 1028 End-Host Network Element Entity 1029 requesting QoS ( Diameter ( Diameter 1030 QoS Client) QoS Server) 1031 | | | 1032 | | |<-- Trigger -- 1033 | | +--------+--------------+ 1034 | | | Authorize request | 1035 | | | Keep session data | 1036 | | |/Authz-time,Session-Id/| 1037 | | +--------+--------------+ 1038 | | | 1039 | |<-- - -- - QIR - - - - - -+ 1040 | |(Initial Request,Decision | 1041 | |(QoS-Resources,Authz-time)| 1042 | +-------+---------+ 1043 | |Install QoS state| 1044 | | + | 1045 | | Authz. session | 1046 | | /Authz-time/ | 1047 | | | 1048 | +-------+---------+ 1049 | + - - - - QIA - - - - - ->| 1050 | | (Result-Code, | 1051 | | QoS-Resources) | 1052 | | +--------+--------------+ 1053 | | | Report for successful | 1054 | | | QoS reservation | 1055 | | |Update of reserved QoS | 1056 | | | resources | 1057 | | +--------+--------------+ 1058 | | QoS Responder 1059 | | Node 1060 | | | 1061 |=====================Data Flow==============....===>| 1062 | | 1063 | (+- - - - - QAR - - - - - >|) 1064 | (|(START,QoS-Resources) |) 1065 | (|< - - - - QAA - - - - - -+) 1066 | | | 1068 Figure 9: Initial QoS Request Authorization for push 1070 The Authorizing Entity keeps authorization session state and SHOULD 1071 save additional information for management of the session (e.g., 1072 Signaling-Session-Id, authentication data) as part of the session 1073 state information. 1075 The final result of the authorization decision is provided in the 1076 QoS-Resources AVP of the QIR message sent by the Authorizing Entity. 1077 The QoS information provided via the QIR is installed by the QoS 1078 Traffic Control function of the Network Element. 1080 One important piece of information from the Authorizing Entity is the 1081 authorization lifetime (carried inside the QIR). The authorization 1082 lifetime allows the Network Element to determine how long the 1083 authorization decision is valid for this particular QoS reservation. 1084 A number of factors may influence the authorized session duration, 1085 such as the user's subscription plan or currently available credits 1086 at the user's account (see Section 8). The authorization duration is 1087 time-based as specified in [RFC3588]. For an extension of the 1088 authorization period, a new QoS-Install-Request/Answer message or 1089 QoS-Authorization-Request/Answer message exchange SHOULD be 1090 initiated. Further aspects of QoS authorization session maintenance 1091 is discussed in Section 4.3, Section 4.4 and Section 8. 1093 The indication of QoS reservation and activation of the data flow, 1094 can be provided by the QoS-Install-Answer message immediately. In 1095 the case of successful enforcement, the Result-Code (= 1096 DIAMETER_SUCCESS, (see Section 7.1)) information is provided in the 1097 QIA message. Note that the reserved QoS resources reported in the 1098 QIA message MAY be different than those initially authorized with the 1099 QIR message, due to the QoS signaling specific behavior (e.g., 1100 receiver-initiated reservations with One-Path-With-Advertisements) or 1101 specific process of QoS negotiation along the data path. When path 1102 coupled signaling is used for QoS reservation along the data path, 1103 QAR/QAA may be used to update the results of QoS reservation and 1104 enforcement following the establishment of data flows. 1106 4.2.3. Discovery and selection of peer Diameter QoS application node 1108 The Diameter QoS application node may obtain information of its peer 1109 nodes (e.g., FQDN, IP address) through static configuration or 1110 dynamic discovery as described in [RFC3588]. In particular, the 1111 Network Element shall perform the relevant operation for Pull mode; 1112 the Authorizing Entity shall perform the relevant operations for Push 1113 mode. 1115 Upon receipt of a trigger to initiate a new Diameter QoS 1116 authorization session, the Diameter QoS application node selects and 1117 retrieves the location information of the peer node and based on some 1118 index information provided by the resource requesting entity. For 1119 instance, it can be the Authorization Entity's ID stored in the 1120 authorization token, the end-host's identity (e.g., NAI [RFC2486]) or 1121 globally routable IP address. 1123 4.3. Session re-authorization 1125 Client and server-side initiated re-authorizations are considered in 1126 the design of the Diameter QoS application. Whether the re- 1127 authorization events are transparent for the resource requesting 1128 entity or result in specific actions in the QoS signaling protocol is 1129 outside the scope of the Diameter QoS application. It is directly 1130 dependent on the capabilities of the QoS signaling protocol. 1132 There are a number of options for policy rules according to which the 1133 NE (AAA client) contacts the Authorizing Entity for re-authorization. 1134 These rules depend on the semantics and contents of the QAA message 1135 sent by the Authorizing Entity: 1137 a. The QAA message contains the authorized parameters of the flow 1138 and its QoS and sets their limits (presumably upper). With these 1139 parameters the Authorizing Entity specifies the services that the 1140 NE can provide and will be financially compensated for. 1141 Therefore, any change or request for change of the parameters of 1142 the flow and its QoS that do not conform to the authorized limits 1143 requires contacting the Authorizing Entity for authorization. 1144 b. The QAA message contains authorized parameters of the flow and 1145 its QoS. The rules that determine whether parameters' changes 1146 require re-authorization are agreed out of band, based on a 1147 Service Level Agreement (SLA) between the domains of the NE and 1148 the Authorizing Entity. 1149 c. The QAA message contains the authorized parameters of the flow 1150 and its QoS. Any change or request for change of these 1151 parameters requires contacting the Authorizing entity for re- 1152 authorization. 1153 d. In addition to the authorized parameters of the flow and its QoS, 1154 the QAA message contains policy rules that determine the NEs 1155 actions in case of change or request for change in authorized 1156 parameters. 1158 Provided options are not exhaustive. Elaborating on any of the 1159 listed approaches is deployment /solution specific and is not 1160 considered in the current document. 1162 In addition, the Authorizing Entity may use RAR to perform re- 1163 authorization with the authorized parameters directly when the re- 1164 authorization is triggered by service request or local events/policy 1165 rules. 1167 4.3.1. Client-Side Initiated Re-Authorization 1169 The Authorizing Entity provides the duration of the authorization 1170 session as part of the QoS-Authorization-Answer message (QAA). At 1171 any time before expiration of this period, a new QoS-Authorization- 1172 Request message (QAR) MAY be sent to the Authorizing Entity. The 1173 transmission of the QAR MAY be triggered, such as, when the Network 1174 Element receives a QoS signaling message that requires modification 1175 of the authorized parameters of an ongoing QoS session, or 1176 authorization lifetime expires. 1178 Authorizing 1179 End-Host Network Element Entity 1180 requesting QoS ( Diameter ( Diameter 1181 QoS Client) QoS Server) 1182 | | | 1183 |=====================Data Flow==========================> 1184 | | | 1185 | +-------+----------+ | 1186 | |Authz-time/CC-Time| | 1187 | | expires | | 1188 | +-------+----------+ | 1189 | +- - - - - QAR - - - - - >| 1190 | |(QoS-Resources, | 1191 | | QoS-Authz-Data,User-ID) | 1192 | +--------+--------------+ 1193 NOTE: | | Authorize request | 1194 Re-authorization | | Update session data | 1195 is transparent to | |/Authz-time,Session-Id/| 1196 the End-Host | +--------+--------------+ 1197 |< - - - - QAA - - - - - -+ 1198 | |(Result-Code, | 1199 | |QoS-Resources,Authz-time)| 1200 | +-------+---------+ | 1201 | |Update QoS state | | 1202 | | + | | 1203 | | Authz. session | | 1204 | | /Authz-time/ | | 1205 | | | | 1206 | +-------+---------+ | 1207 | | | 1208 |=====================Data Flow==========================> 1209 | | 1211 Figure 10: Client-side initiated QoS re-authorization 1213 4.3.2. Server-Side Initiated Re-Authorization 1215 The Authorizing Entity MAY initiate a QoS re-authorization by issuing 1216 a Re-Auth-Request message (RAR) as defined in the Diameter base 1217 protocol [RFC3588], which may include the parameters of the re- 1218 authorized QoS state: reserved resources, duration of the 1219 reservation, identification of the QoS enabled flow/QoS signaling 1220 session for re-installation of the resource state by the QoS Traffic 1221 Control function of the Network Element. 1223 A Network Element that receives such a RAR message with Session-Id 1224 matching a currently active QoS session acknowledges the request by 1225 sending the Re-Auth-Answer (RAA) message towards the Authorizing 1226 entity. 1228 If RAR does not include any parameters of the re-authorized QoS 1229 state, the Network Element MUST initiate a QoS re-authorization by 1230 sending a QoS-Authorization-Request (QAR) message towards the 1231 Authorizing entity. 1233 Authorizing 1234 End-Host Network Element Entity 1235 requesting QoS ( Diameter ( Diameter 1236 QoS Client) QoS Server) 1237 | | | 1238 | | |<-- Trigger -- 1239 | | +--------+--------------+ 1240 | | | Authorize request | 1241 | | | Keep session data | 1242 | | |/Authz-time,Session-Id/| 1243 | | +--------+--------------+ 1244 | | | 1245 | |<-- - -- - RAR - - - - - -+ 1246 | |(Request,Decision | 1247 | |(QoS-Resources,Authz-time)| 1248 | +-------+---------+ 1249 | |Install QoS state| 1250 | | + | 1251 | | Authz. session | 1252 | | /Authz-time/ | 1253 | | | 1254 | +-------+---------+ 1255 | + - - - - RAA - - - - - ->| 1256 | | (Result-Code, | 1257 | | QoS-Resources) | 1258 | | +--------+--------------+ 1259 | | | Report for successful | 1260 | | | QoS reservation | 1261 | | |Update of reserved QoS | 1262 | | | resources | 1263 | | +--------+--------------+ 1264 | | | 1266 Figure 11: Server-side Initiated QoS re-authorization 1268 4.4. Session Termination 1270 4.4.1. Client-Side Initiated Session Termination 1272 The authorization session for an installed QoS reservation state MAY 1273 be terminated by the Diameter client by sending a Session- 1274 Termination-Request message (STR) to the Diameter server. This is a 1275 Diameter base protocol function and it is defined in [RFC3588]. 1276 Session termination can be caused by a QoS signaling messaging 1277 requesting deletion of the existing QoS reservation state or it can 1278 be caused as a result of a soft-state expiration of the QoS 1279 reservation state. 1281 Authorizing 1282 End-Host Network Element Entity 1283 requesting QoS ( Diameter ( Diameter 1284 QoS Client) QoS Server) 1285 | | | 1286 |==Data Flow==>X /Stop of the data flow/ | 1287 | | | 1288 +---QoS-Reserve---->| | 1289 | (Delete QoS +- - - - - STR - - - - - >| 1290 | reservation) | +--------+--------------+ 1291 | | | Remove authorization | 1292 |<--QoS-Response----+ | session state | 1293 | | +--------+--------------+ 1294 |< - - - - STA - - - - - -+ 1295 +-------+--------+ | 1296 |Delete QoS state| 1297 +-------+--------+ QoS Responder 1298 | Node 1299 +----------QoS-Reserve-----....--->| 1300 | (Delete QoS | 1301 | reservation) | 1302 |<---------QoS-Response----....----+ 1303 | | 1305 Figure 12: Client-Side Initiated Session Termination 1307 4.4.2. Server-Side Initiated Session Termination 1309 At anytime during a session the Authorizing Entity MAY send an Abort- 1310 Session-Request message (ASR) to the Network Element. This is a 1311 Diameter base protocol function and it is defined in [RFC3588]. 1312 Possible reasons for initiating the ASR message to the Network 1313 Element are insufficient credits or session termination at the 1314 application layer. The ASR message results in termination of the 1315 authorized session, release of the reserved resources at the Network 1316 Element and transmission of an appropriate QoS signaling message 1317 indicating a notification to other Network Elements aware of the 1318 signaling session. 1320 Authorizing 1321 End-Host Network Element Entity 1322 requesting QoS ( Diameter ( Diameter 1323 QoS Client) QoS Server) 1324 | | | 1325 |=====================Data Flow==========================> 1326 | | 1327 | |< - - - - ASR - - - - - -+ 1328 | | | 1329 |====Data Flow=====>X | QoS Responder 1330 | | | Node 1331 |<--QoS-Notify------+----------QoS-Reserve-----....--->| 1332 | | (Delete QoS | | 1333 | reservation) | 1334 +-------+--------+ | 1335 |Delete QoS state| | 1336 +-------+--------+ | 1337 +- - - - - ASA - - - - - >| 1338 | +--------+--------------+ 1339 | | Remove authorization | 1340 | | session state | 1341 | +--------+--------------+ 1342 | QoS Responder 1343 | Node 1344 |<---------QoS-Response----....----+ 1345 | | 1347 Figure 13: Server-Side Initiated Session Termination 1349 5. QoS Application Messages 1351 The Diameter QoS Application requires the definition of new mandatory 1352 AVPs and Command-codes (see Section 3 of [RFC3588]). Four new 1353 Diameter messages are defined along with Command-Codes whose values 1354 MUST be supported by all Diameter implementations that conform to 1355 this specification. 1357 Command-Name Abbrev. Code Reference 1358 QoS-Authz-Request QAR [TBD] Section 5.1 1359 QoS-Authz-Answer QAA [TBD] Section 5.2 1360 QoS-Install-Request QIR [TBD] Section 5.3 1361 QoS-Install-Answer QIA [TBD] Section 5.4 1363 In addition, the following Diameter Base protocol messages are used 1364 in the Diameter QoS application: 1366 Command-Name Abbrev. Code Reference 1367 Re-Auth-Request RAR 258 RFC 3588 1368 Re-Auth-Answer RAA 258 RFC 3588 1369 Abort-Session-Request ASR 274 RFC 3588 1370 Abort-Session-Answer ASA 274 RFC 3588 1371 Session-Term-Request STR 275 RFC 3588 1372 Session-Term-Answer STA 275 RFC 3588 1374 Diameter nodes conforming to this specification MAY advertise support 1375 by including the value of TBD in the Auth-Application-Id or the Acct- 1376 Application-Id AVP of the Capabilities-Exchange-Request and 1377 Capabilities-Exchange-Answer commands, see [RFC3588]. 1379 The value of TBD MUST be used as the Application-Id in all QAR/QAA 1380 and QIR/QIA commands. 1382 The value of zero (0) SHOULD be used as the Application-Id in all 1383 STR/STA, ASR/ASA, and RAR/RAA commands, because these commands are 1384 defined in the Diameter base protocol and no additional mandatory 1385 AVPs for those commands are defined in this document. 1387 5.1. QoS-Authorization Request (QAR) 1389 The QoS-Authorization-Request message (QAR) indicated by the Command- 1390 Code field (see Section 3 of [RFC3588]) set to TBD and 'R' bit set in 1391 the Command Flags field is used by Network elements to request 1392 quality of service related resource authorization for a given flow. 1394 The QAR message MUST carry information for signaling session 1395 identification, Authorizing Entity identification, information about 1396 the requested QoS, and the identity of the QoS requesting entity. In 1397 addition, depending on the deployment scenario, an authorization 1398 token and credentials of the QoS requesting entity SHOULD be 1399 included. 1401 The message format, presented in ABNF form [RFC2234], is defined as 1402 follows: 1404 ::= < Diameter Header: XXX, REQ, PXY > 1405 < Session-Id > 1406 { Auth-Application-Id } 1407 { Origin-Host } 1408 { Origin-Realm } 1409 { Destination-Realm } 1410 { Auth-Request-Type } 1411 [ Destination-Host ] 1412 [ User-Name ] 1413 * [ QoS-Resources ] 1414 [ QoS-Authz-Data ] 1415 [ Bound-Auth-Session-Id ] 1416 * [ AVP ] 1418 5.2. QoS-Authorization Answer (QAA) 1420 The QoS-Authorization-Answer message (QAA), indicated by the Command- 1421 Code field set to TBD and 'R' bit cleared in the Command Flags field 1422 is sent in response to the QoS-Authorization-Request message (QAR). 1423 If the QoS authorization request is successfully authorized, the 1424 response will include the AVPs to allow authorization of the QoS 1425 resources and transport plane gating information. 1427 The message format is defined as follows: 1429 ::= < Diameter Header: XXX, PXY > 1430 < Session-Id > 1431 { Auth-Application-Id } 1432 { Auth-Request-Type } 1433 { Result-Code } 1434 { Origin-Host } 1435 { Origin-Realm } 1436 * [ QoS-Resources ] 1437 [ Acc-Multisession-Id ] 1438 [ Session-Timeout ] 1439 [ Authz-Session-Lifetime ] 1440 [ Authz-Grace-Period ] 1442 * [ AVP ] 1444 5.3. QoS-Install Request (QIR) 1446 The QoS-Install Request message (QIR), indicated by the Command-Code 1447 field set to TDB and 'R' bit set in the Command Flags field is used 1448 by Authorizing entity to install or update the QoS parameters and the 1449 flow state of an authorized flow at the transport plane element. 1451 The message MUST carry information for signaling session 1452 identification or identification of the flow to which the provided 1453 QoS rules apply, identity of the transport plane element, description 1454 of provided QoS parameters, flow state and duration of the provided 1455 authorization. 1457 The message format is defined as follows: 1459 ::= < Diameter Header: XXX, REQ, PXY > 1460 < Session-Id > 1461 { Auth-Application-Id } 1462 { Origin-Host } 1463 { Origin-Realm } 1464 { Destination-Realm } 1465 { Auth-Request-Type } 1466 [ Destination-Host ] 1467 * [ QoS-Resources ] 1468 [ Session-Timeout ] 1469 [ Authz-Session-Lifetime ] 1470 [ Authz-Grace-Period ] 1471 [ Authz-Session-Volume ] 1472 * [ AVP ] 1474 5.4. QoS-Install Answer (QIA) 1476 The QoS-Install Answer message (QIA), indicated by the Command-Code 1477 field set to TBD and 'R' bit cleared in the Command Flags field is 1478 sent in response to the QoS-Install Request message (QIR) for 1479 confirmation of the result of the installation of the provided QoS 1480 reservation instructions. 1482 The message format is defined as follows: 1484 ::= < Diameter Header: XXX, PXY > 1485 < Session-Id > 1486 { Auth-Application-Id } 1487 { Origin-Host } 1488 { Origin-Realm } 1489 { Result-Code } 1490 * [ QoS-Resources ] 1491 * [ AVP ] 1493 5.5. Re-Auth-Request (RAR) 1495 The Re-Auth-Request message (RAR), indicated by the Command-Code 1496 field set to 258 and the 'R' bit set in the Command Flags field, is 1497 sent by the Authorizing Entity to the Network Element in order to 1498 initiate the QoS re-authorization from DQA server side. 1500 If the RAR command is received by the Network Element without any 1501 parameters of the re-authorized QoS state, the Network Element MUST 1502 initiate a QoS re-authorization by sending a QoS-Authorization- 1503 Request (QAR) message towards the Authorizing entity. 1505 The message format is defined as follows: 1507 ::= < Diameter Header: 258, REQ, PXY > 1508 < Session-Id > 1509 { Auth-Application-Id } 1510 { Origin-Host } 1511 { Origin-Realm } 1512 { Destination-Realm } 1513 { Auth-Request-Type } 1514 [ Destination-Host ] 1515 * [ QoS-Resources ] 1516 [ Session-Timeout ] 1517 [ Authz-Session-Lifetime ] 1518 [ Authz-Grace-Period ] 1519 [ Authz-Session-Volume ] 1520 * [ AVP ] 1522 5.6. Re-Auth-Answer (RAA) 1524 The Re-Auth-Answer message (RAA), indicated by the Command-Code field 1525 set to 258 and the 'R' bit cleared in the Command Flags field, is 1526 sent by the Network Element to the Authorizing Entity in response to 1527 the RAR command. 1529 The message format is defined as follows: 1531 ::= < Diameter Header: 258, PXY > 1532 < Session-Id > 1533 { Auth-Application-Id } 1534 { Origin-Host } 1535 { Origin-Realm } 1536 { Result-Code } 1537 * [ QoS-Resources ] 1538 * [ AVP ] 1540 6. QoS Application State Machine 1542 The QoS application reuses the authorization state machine defined in 1543 Section 8.1 of the Base Protocol ([RFC3588]) with its own messages as 1544 defined in Section 5 and QoS AVPs as defined in Section 7. 1546 6.1. Supplemented states for push mode 1548 In addition to the reused state machines, the following states are 1549 supplemented to first 2 state machines in which the session state is 1550 maintained on the Server, and MUST be supported in any QoS 1551 application implementations in support of server initiated push mode 1552 (see (Section 4.2.2)). 1554 The following states are supplemented to the state machine on the 1555 server: 1557 SERVER, STATEFUL 1558 State Event Action New State 1559 ------------------------------------------------------------- 1560 Idle An application or local Send Pending 1561 event triggers an initial QIR initial 1562 QoS request to the server request 1564 Pending Received QIA with a failed Cleanup Idle 1565 Result-Code 1567 Pending Received QIA with Result-Code Update Open 1568 = SUCCESS session 1569 Pending Error in processing received Send Discon 1570 QIA with Result-Code = SUCCESS ASR 1572 The following states are supplemented to the state machine on the 1573 client: 1575 CLIENT, STATEFUL 1576 State Event Action New State 1577 ------------------------------------------------------------- 1578 Idle QIR initial request Send Open 1579 received and successfully QIA initial 1580 processed answer, 1581 reserve resources 1583 Idle QIR initial request Send Idle 1584 received but not QIA initial 1585 successfully processed answer with 1586 Result-Code 1587 != SUCCESS 1589 7. QoS Application AVPs 1591 Each of the AVPs identified in the QoS-Authorization-Request/Answer 1592 and QoS-Install-Request/Answer messages and the assignment of their 1593 value(s) is given in this section. 1595 7.1. Reused Base Protocol AVPs 1597 The QoS application uses a number of session management AVPs, defined 1598 in the Base Protocol ([RFC3588]). 1600 Attribute Name AVP Code Reference [RFC3588] 1601 Origin-Host 264 Section 6.3 1602 Origin-Realm 296 Section 6.4 1603 Destination-Host 293 Section 6.5 1604 Destination-Realm 283 Section 6.6 1605 Auth-Application-Id 258 Section 6.8 1606 Result-Code 268 Section 7.1 1607 Auth-Request-Type 274 Section 8.7 1608 Session-Id 263 Section 8.8 1609 Authz-Lifetime 291 Section 8.9 1610 Authz-Grace-Period 276 Section 8.10 1611 Session-Timeout 27 Section 8.13 1612 User-Name 1 Section 8.14 1614 The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to 1615 Diameter applications. The value of the Auth-Application-Id for the 1616 Diameter QoS application is TBD. 1618 7.2. QoS Application Defined AVPs 1620 This document reuses the AVPs defined in Section 4 of 1621 [I-D.ietf-dime-qos-attributes]. 1623 This section lists the AVPs that are introduced specifically for the 1624 QoS application. The following new AVPs are defined: Bound-Auth- 1625 Session-Id and the QoS-Authz-Data AVP. 1627 The following table describes the Diameter AVPs newly defined in this 1628 document for usage with the QoS Application, their AVP code values, 1629 types, possible flag values, and whether the AVP may be encrypted. 1631 +-------------------+ 1632 | AVP Flag rules | 1633 +----------------------------------------------|----+---+----+-----+ 1634 | AVP Section | | |SHLD| MUST| 1635 | Attribute Name Code Defined Data Type |MUST|MAY| NOT| NOT| 1636 +----------------------------------------------+----+---+----+-----+ 1637 |QoS-Authz-Data TBD 6.4 Grouped | M | P | | V | 1638 |Bound-Auth-Session-Id TBD 6.4 UTF8String | M | P | | V | 1639 +----------------------------------------------+----+---+----+-----+ 1640 |M - Mandatory bit. An AVP with "M" bit set and its value MUST be | 1641 | supported and recognized by a Diameter entity in order the | 1642 | message, which carries this AVP, to be accepted. | 1643 |P - Indicates the need for encryption for end-to-end security. | 1644 |V - Vendor specific bit that indicates whether the AVP belongs to | 1645 | a address space. | 1646 +------------------------------------------------------------------+ 1648 QoS-Authz-Data 1650 The QoS-Authz-Data AVP (AVP Code TBD) is of type OctetString. It 1651 is a container that carries application session or user specific 1652 data that has to be supplied to the Authorizing entity as input to 1653 the computation of the authorization decision. 1655 Bound-Authentication-Session-Id 1657 The Bound-Authentication-Session AVP (AVP Code TBD) is of type 1658 UTF8String. It carries the id of the Diameter authentication 1659 session that is used for the network access authentication (NASREQ 1660 authentication session). It is used to tie the QoS authorization 1661 request to a prior authentication of the end host done by a co- 1662 located application for network access authentication (Diameter 1663 NASREQ) at the QoS NE. 1665 8. Accounting 1667 A Network Element may start an accounting session by sending an 1668 Accounting-Request message (ACR) after successful QoS reservation and 1669 activation of the data flow (see Figure 7 and Figure 9). After every 1670 successful re-authorization procedure (see Figure 10 and Figure 11), 1671 the Network element may initiate an interim accounting message 1672 exchange. After successful session termination (see Figure 12 and 1673 Figure 13), the Network element may initiate a final exchange of 1674 accounting messages for terminating of the accounting session and 1675 reporting final records for the usage of the QoS resources reserved. 1676 It should be noted that the two sessions (authorization and 1677 accounting) have independent management by the Diameter base 1678 protocol, which allows for finalizing the accounting session after 1679 the end of the authorization session. 1681 The detailed QoS accounting procedures are out of scope in this 1682 document. 1684 9. Examples 1686 9.1. Example call flow for pull mode 1688 This section presents an example of the interaction between the end 1689 host and Diameter QoS application entities using Pull mode. The 1690 application layer signaling is, in this example, provided using SIP. 1691 Signaling for a QoS resource reservation is done using the QoS NSLP. 1692 The authorization of the QoS reservation request is done by the 1693 Diameter QoS application (DQA). 1695 End-Host SIP Server Correspondent 1696 requesting QoS (DQA Server) Node 1698 | | | 1699 ..|....Application layer SIP signaling.......|..............|.. 1700 . | Invite (SDP) | | . 1701 . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | . 1702 . | 100 Trying | | . 1703 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| . 1704 . | +-.-.-.....-.-.> . 1705 . | | 180 SDP' | . 1706 . | <-.-.-.....-.-.+ . 1707 . | +--------+--------+ | . 1708 . | |Authorize session| | . 1709 . | | parameters | | . 1710 . | 180 (Session parameters) +--------+--------+ | . 1711 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | . 1712 ..|..........................................|... ..........|.. 1713 | | | 1714 | +------------+ | | 1715 | | NE | | | 1716 | |(DQA Client)| | | 1717 | +------+-----+ | | 1718 | | | | 1719 |QoS NSLP Reserve | | | 1720 +------------------> QAR | | 1721 | (POLICY_DATA>v +- - - - -<>- - - -> | 1722 | QSPEC) v >===>(Destination-Host, | | 1723 | v >=======>QoS-Authz-Data ++------------+ | 1724 | >===========>QoS-Resources) |Authorize | | 1725 | | |QoS resources| | 1726 | | ++------------+ | 1727 | | QAA | | 1728 | <- - - - -<>- - - -+ | 1729 | |(Result-Code, | | 1730 | |QoS-Resources, | | 1731 | |Authz-Lifetime) | | 1732 | +---------+--------+ | | 1733 | |Install QoS state1| | | 1734 | |+ Authz. session | | | 1735 | +---------+--------+ | | 1736 | |QoS NSLP Reserve | 1737 | +---------------..............---------> 1738 | | | 1739 | | QoS NSLP Response| 1740 |QoS NSLP Response <---------------..............---------+ 1741 <------------------+ | 1742 | | QoS NSLP Query| 1743 |QoS NSLP Query <---------------..............---------+ 1744 <------------------+ | 1745 |QoS NSLP Reserve | | 1746 +------------------> QAR | | 1747 | +- - - - -<>- - - -> | 1748 | | +---+---------+ | 1749 | | |Authorize | | 1750 | | |QoS resources| | 1751 | | QAA +---+---------+ | 1752 | <- - - - -<>- - - -+ | 1753 | +---------+--------+ | | 1754 | |Install QoS state2| | 1755 | |+ Authz. session | | 1756 | +---------+--------+ | 1757 | | QoS NSLP Reserve | 1758 | +---------------..............---------> 1759 | | QoS NSLP Response| 1760 |QoS NSLP Response <---------------..............---------+ 1761 <------------------+ | 1762 | | | 1763 /------------------+--Data Flow---------------------------\ 1764 \------------------+--------------------------------------/ 1765 | | | 1767 .-.-.-.-. SIP signaling 1768 --------- QoS NSLP signaling 1769 - - - - - Diameter QoS Application messages 1770 ========= Mapping of objects between QoS and AAA protocol 1772 Figure 26: QoS Authorization Example - Pull Mode 1774 The communication starts with SIP signaling between the two end 1775 points and the SIP server for negotiation and authorization of the 1776 requested service and its parameters (see Figure 26). As a part of 1777 the process, the SIP server verifies whether the user at Host A is 1778 authorized to use the requested service (and potentially the ability 1779 to be charged for the service usage). Negotiated session parameters 1780 are provided to the end host. 1782 Subsequently, Host A initiates a QoS signaling message towards Host 1783 B. It sends a QoS NSLP Reserve message, in which it includes 1784 description of the required QoS (QSPEC object) and authorization data 1785 for negotiated service session (part of the POLICY_DATA object). 1786 Authorization data includes, as a minimum, the identity of the 1787 authorizing entity (e.g., the SIP server) and an identifier of the 1788 application service session for which QoS resources are requested. 1790 A QoS NSLP Reserve message is intercepted and processed by the first 1791 QoS aware Network Element. The NE uses the Diameter QoS application 1792 to request authorization for the received QoS reservation request. 1793 The identity of the Authorizing Entity (in this case the SIP server 1794 that is co-located with a Diameter server) is put into the 1795 Destination-Host AVP, any additional session authorization data is 1796 encapsulated into the QoS-Authz-Data AVP and the description of the 1797 QoS resources is included into QoS-Resources AVP. These AVPs are 1798 included into a QoS Authorization Request message, which is sent to 1799 the Authorizing entity. 1801 A QAR message will be routed through the AAA network to the 1802 Authorizing Entity. The Authorizing Entity verifies the requested 1803 QoS against the QoS resources negotiated for the service session and 1804 replies with QoS-Authorization answer (QAA) message. It carries the 1805 authorization result (Result-Code AVP) and the description of the 1806 authorized QoS parameters (QoS-Resources AVP), as well as duration of 1807 the authorization session (Authorization-Lifetime AVP). 1809 The NE interacts with the traffic control function and installs the 1810 authorized QoS resources and forwards the QoS NSLP Reserve message 1811 further along the data path. Moreover, the NE may serve as a 1812 signaling proxy and process the QoS signaling (e.g. initiation or 1813 termination of QoS signaling) based on the QoS decision received from 1814 the authorizing entity. 1816 9.2. Example call flow for push mode 1818 This section presents an example of the interaction between the end- 1819 host and Diameter QoS application entities using Push Mode. The 1820 application layer signaling is, in this example, provided using SIP. 1821 Signaling for a QoS resource reservation is done using the QoS NSLP. 1822 The authorization of the QoS reservation request is done by the 1823 Diameter QoS application (DQA). 1825 End-Host NE SIP Server Correspondent 1826 requesting QoS (DQA Client) (DQA Server) Node 1827 | | | | 1828 ..|....Application layer SIP signaling..........|..............|.. 1829 . | Invite(SDP offer)| | | . 1830 . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.> | . 1831 . | 100 Trying | | | . 1832 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | . 1833 . |.............................................|..............| . 1834 | | +---------+-------------+| 1835 | | | Authorize request || 1836 | | | Keep session data || 1837 | | |/Authz-time,Session-Id/|| 1838 | | +---------+-------------+| 1839 | | | | 1840 | |<-- - -- - QIR - -- - -- -+ | 1841 | |(Initial Request,Decision | | 1842 | |(QoS-Resources,Authz-time)| | 1843 | +-------+---------+ | | 1844 | |Install QoS state| | | 1845 | | + | | | 1846 | | Authz. session | | | 1847 | | /Authz-time/ | | | 1848 | +-------+---------+ | | 1849 | + - - -- - QIA - - - - - ->| | 1850 | | (Result-Code, | | 1851 | | QoS-Resources) | | 1852 | | +----------+------------+ | 1853 | | | Report for successful | | 1854 | | | QoS reservation | | 1855 | | |Update of reserved QoS | | 1856 | | | resources | | 1857 | | +----------+------------+ | 1858 . | | | Invite (SDP) | . 1859 . | | +-.-.-.....-.-.> . 1860 . | 180 (Ringing) | | . 1861 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.<.-.-.-.-.-.-.-+ . 1862 . | | | 200 OK (SDP)| . 1863 . | | <-.-.-.....-.-.+ . 1864 | | +--------+-----------+ | 1865 | | |re-Authorize session| | 1866 | | | parameters | | 1867 | | +--------+-----------+ | 1868 | <- - - - - - RAR - - - - - + | 1869 | +---------+--------+ | | 1870 | |Activate QoS state| | | 1871 | +---------+--------+ | | 1872 | +- - - - - - RAA - - - - - > | 1873 . | 200 (SDP answer) | | | . 1874 . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | . 1876 | | | 1877 /------------------+-----Data Flow---------------------------\ 1878 \------------------+-----------------------------------------/ 1879 | | | 1881 .-.-.-.-. SIP signaling 1882 - - - - - Diameter QoS Application messages 1884 Figure 27: QoS Authorization Example - Push Mode 1886 The communication starts with SIP signaling between the two end 1887 points and the SIP server for negotiation and authorization of the 1888 requested service and its parameters (see Figure 27). As a part of 1889 the process, the SIP server verifies whether the user at Host A is 1890 authorized to use the requested service (and potentially the ability 1891 to be charged for the service usage). The DQA server is triggered to 1892 authorize the QoS request based on session parameters (i.e., SDP 1893 offer), initiate a Diameter QoS authorization session and install 1894 authorized QoS state to the Network Element via QIR message. 1896 The DQA server may obtain the info of peer DQA client from pre- 1897 configured information or query the DNS based on Host A's identity or 1898 IP address (In this case a DQA server is co-located with a SIP server 1899 and a DQA client is co-located with a Network element). The identity 1900 of Network Element is put into the Destination-Host AVP, the 1901 description of the QoS resources is included into QoS-Resources AVP, 1902 as well as duration of the authorization session (Authorization- 1903 Lifetime AVP). The NE interacts with the traffic control function 1904 and reserves the authorized QoS resources accordingly, for instance, 1905 the NE may serve as a signaling proxy and process the QoS signaling 1906 (e.g. initiation or termination of QoS signaling) based on the QoS 1907 decision received from the authorizing entity. 1909 With successful QoS authorization, the SDP offer in SIP Invite is 1910 forwarded to Host B. Host B sends back a 18x (ringing) message 1911 towards Host A and processes the SDP. Once Host B accepts the call, 1912 it sends back a 200 OK, in which it includes description of the 1913 accepted session parameters (i.e. SDP answer). 1915 The DQA server may verifies the accepted QoS against the pre- 1916 authorized QoS resources, and sends a Diameter RAR message to the DQA 1917 client in the network element for activating the installed policies 1918 and commit the resource allocation. With successful QoS enforcement, 1919 the 200 OK is forwarded towards Host A. 1921 Note that the examples above show a sender-initiated reservation from 1922 the end host towards the corresponding node and a receiver-initiated 1923 reservation from the correspondent node towards the end host. 1925 10. IANA Considerations 1927 This section contains the namespaces that have either been created in 1928 this specification or had their values assigned to existing 1929 namespaces managed by IANA. 1931 10.1. AVP Codes 1933 IANA is requested to allocate two AVP codes to the following: 1935 Registry: 1936 AVP Code Attribute Name Reference 1937 ----------------------------------------------------------- 1938 to be assigned QoS-Authz-Data Section 6.4 1939 to be assigned Bound-Auth-Session-Id Section 6.4 1941 10.2. AVP specific values 1943 IANA is requested to allocate the following sub-registry values. 1945 Sub-registry: Auth-Application-Id AVP Values (code 258) 1946 Registry: 1947 AVP Values Attribute Name Reference 1948 ------------- ------------------------------------------- 1949 to be assigned DIAMETER-QOS-NOSUPPORT Section 5 1950 to be assigned DIAMETER-QOS-SUPPORT Section 5 1952 Sub-registry: Acct-Application-Id AVP Values (code 259) 1953 Registry: 1954 AVP Values Attribute Name Reference 1955 ------------- ------------------------------------------- 1956 to be assigned DIAMETER-QOS-NOSUPPORT Section 5 1957 to be assigned DIAMETER-QOS-SUPPORT Section 5 1959 10.3. AVP flags 1961 There are no new AVP flags defined for either the QoS-Authz-Data AVP 1962 or the Bound-Ath-Session-ID AVP. 1964 10.4. Application IDs 1966 IANA is requested to allocate the following application ID using the 1967 next value from the 7-16777215 range. 1969 Registry: 1970 ID values Name Reference 1971 ----------------------------------------------------------- 1972 to be asigned Diameter QoS application Section 5 1974 10.5. Command Codes 1976 IANA is requested to allocate command code values for the following 1977 from the range 289-299. 1979 Registry: 1980 Code Value Name Reference 1981 ----------------------------------------------------------- 1982 to be assigned QoS-Authz-Request (QAR) Section 5.1 1983 to be assigned QoS-Authz-Answer (QAA) Section 5.2 1984 to be assigned QoS-Install-Request (QIR) Section 5.3 1985 to be assigned QoS-Install-Answer (QIA) Section 5.4 1987 11. Security Considerations 1989 This document describes a mechanism for performing authorization of a 1990 QoS reservation at a third party entity. Therefore, it is necessary 1991 that the QoS signaling application to carry sufficient information 1992 that should be forwarded to the backend AAA server. This 1993 functionality is particularly useful in roaming environments where 1994 the authorization decision is most likely provided at an entity where 1995 the user can be authorized, such as in the home realm. 1997 QoS signaling application MAY re-use the authenticated identities 1998 used for the establishment of the secured transport channel for the 1999 signaling messages, e.g., TLS or IPsec between the end host and the 2000 policy aware QoS NE. In addition, a collocation of the QoS NE with, 2001 for example, the Diameter NASREQ application (see [RFC4005]) may 2002 allow the QoS authorization to be based on the authenticated identity 2003 used during the network access authentication protocol run. If a co- 2004 located deployment is not desired then special security protection is 2005 required to ensure that arbitrary nodes cannot reuse a previous 2006 authentication exchange to perform an authorization decision. 2008 Additionally, QoS authorization might be based on the usage of 2009 authorization tokens that are generated by the Authorizing Entity and 2010 provided to the end host via application layer signaling. 2012 The impact of the existence of different authorization models is 2013 (with respect to this Diameter QoS application) the ability to carry 2014 different authentication and authorization information. 2016 12. Acknowledgements 2018 The authors would like to thank John Loughney and Allison Mankin for 2019 their input to this document. In September 2005 Robert Hancock, 2020 Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis and 2021 Elwyn Davies provided a detailed review. Robert also provided us 2022 with good feedback earlier in 2005. Jerry Ash provided us review 2023 comments late 2005/early 2006. Rajith R provided some inputs to the 2024 document early 2007 2026 13. Contributors 2028 The authors would like to thank Tseno Tsenov (tseno.tsenov@gmail.com) 2029 and Frank Alfano (falfano@lucent.com) for starting the Diameter 2030 Quality of Service work within the IETF, for your significant draft 2031 contributions and for being the driving force for the first few draft 2032 versions. 2034 [Editor's Note: A bit of history needs to be included here.] 2036 14. References 2038 14.1. Normative References 2040 [I-D.ietf-dime-qos-attributes] 2041 Korhonen, J., Tschofenig, H., Arumaithurai, M., and M. 2042 Jones, "Quality of Service Attributes for Diameter", 2043 draft-ietf-dime-qos-attributes-04 (work in progress), 2044 January 2008. 2046 [I-D.ietf-dime-qos-parameters] 2047 Korhonen, J. and H. Tschofenig, "Quality of Service 2048 Parameters for Usage with the AAA Framework", 2049 draft-ietf-dime-qos-parameters-01 (work in progress), 2050 September 2007. 2052 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2053 Requirement Levels", BCP 14, RFC 2119, March 1997. 2055 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2056 Specifications: ABNF", RFC 2234, November 1997. 2058 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 2059 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2061 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 2062 "Diameter Network Access Server Application", RFC 4005, 2063 August 2005. 2065 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 2066 Loughney, "Diameter Credit-Control Application", RFC 4006, 2067 August 2005. 2069 14.2. Informative References 2071 [I-D.ietf-nsis-ntlp] 2072 Schulzrinne, H. and R. Hancock, "GIST: General Internet 2073 Signalling Transport", draft-ietf-nsis-ntlp-14 (work in 2074 progress), July 2007. 2076 [I-D.ietf-nsis-qos-nslp] 2077 Manner, J., "NSLP for Quality-of-Service Signaling", 2078 draft-ietf-nsis-qos-nslp-15 (work in progress), July 2007. 2080 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 2081 Services", RFC 2210, September 1997. 2083 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 2084 RFC 2486, January 1999. 2086 [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R., 2087 and A. Sastry, "COPS usage for RSVP", RFC 2749, 2088 January 2000. 2090 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 2091 for Policy-based Admission Control", RFC 2753, 2092 January 2000. 2094 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2095 "Remote Authentication Dial In User Service (RADIUS)", 2096 RFC 2865, June 2000. 2098 [RFC3313] Marshall, W., "Private Session Initiation Protocol (SIP) 2099 Extensions for Media Authorization", RFC 3313, 2100 January 2003. 2102 [RFC3520] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, 2103 "Session Authorization Policy Element", RFC 3520, 2104 April 2003. 2106 [RFC3521] Hamer, L-N., Gage, B., and H. Shieh, "Framework for 2107 Session Set-up with Media Authorization", RFC 3521, 2108 April 2003. 2110 [RFC4027] Josefsson, S., "Domain Name System Media Types", RFC 4027, 2111 April 2005. 2113 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2114 Description Protocol", RFC 4566, July 2006. 2116 Authors' Addresses 2118 Dong Sun (editor) 2119 Alcatel-Lucent 2120 600-700 Mountain Ave 2121 Murray Hill, NJ 07974 2122 USA 2124 Phone: +1 908 582 2617 2125 Email: dongsun@alcatel-lucent.com 2127 Peter J. McCann 2128 Motorola Labs 2129 1301 E. Algonquin Rd 2130 Schaumburg, IL 60196 2131 USA 2133 Phone: +1 847 576 3440 2134 Email: pete.mccann@motorola.com 2136 Hannes Tschofenig 2137 Nokia Siemens Networks 2138 Linnoitustie 6 2139 Espoo 02600 2140 Finland 2142 Phone: +358 (50) 4871445 2143 Email: Hannes.Tschofenig@nsn.com 2144 URI: http://www.tschofenig.com 2146 Tina Tsou 2147 Huawei 2148 Shenzhen, 2149 P.R.C 2151 Email: tena@huawei.com 2152 Avri Doria 2153 Lulea University of Technology 2154 Arbetsvetenskap 2155 Lulea, SE-97187 2156 Sweden 2158 Email: avri@ltu.se 2160 Glen Zorn 2161 Aruba Networks 2162 1322 Crossman Avenue 2163 Sunnyvale, CA 94089-1113 2164 USA 2166 Email: gwz@arubanetworks.com 2168 Full Copyright Statement 2170 Copyright (C) The IETF Trust (2008). 2172 This document is subject to the rights, licenses and restrictions 2173 contained in BCP 78, and except as set forth therein, the authors 2174 retain all their rights. 2176 This document and the information contained herein are provided on an 2177 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2178 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2179 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2180 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2181 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2182 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2184 Intellectual Property 2186 The IETF takes no position regarding the validity or scope of any 2187 Intellectual Property Rights or other rights that might be claimed to 2188 pertain to the implementation or use of the technology described in 2189 this document or the extent to which any license under such rights 2190 might or might not be available; nor does it represent that it has 2191 made any independent effort to identify any such rights. Information 2192 on the procedures with respect to rights in RFC documents can be 2193 found in BCP 78 and BCP 79. 2195 Copies of IPR disclosures made to the IETF Secretariat and any 2196 assurances of licenses to be made available, or the result of an 2197 attempt made to obtain a general license or permission for the use of 2198 such proprietary rights by implementers or users of this 2199 specification can be obtained from the IETF on-line IPR repository at 2200 http://www.ietf.org/ipr. 2202 The IETF invites any interested party to bring to its attention any 2203 copyrights, patents or patent applications, or other proprietary 2204 rights that may cover technology that may be required to implement 2205 this standard. Please address the information to the IETF at 2206 ietf-ipr@ietf.org. 2208 Acknowledgment 2210 Funding for the RFC Editor function is provided by the IETF 2211 Administrative Support Activity (IASA).