idnits 2.17.00 (12 Aug 2021) /tmp/idnits57413/draft-tschofenig-radext-qos-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1015. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 5, 2007) is 5549 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: draft-ietf-dime-diameter-qos has been published as RFC 5866 -- Obsolete informational reference (is this intentional?): RFC 3576 (ref. '9') (Obsoleted by RFC 5176) == Outdated reference: draft-ietf-radext-filter has been published as RFC 4849 == Outdated reference: A later version (-22) exists of draft-lior-radius-prepaid-extensions-11 == Outdated reference: draft-ietf-nsis-qspec has been published as RFC 5975 == Outdated reference: draft-ietf-sipping-trait-authz has been published as RFC 4484 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-01 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS EXTensions (radext) H. Tschofenig 3 Internet-Draft Siemens 4 Expires: September 6, 2007 A. Mankin 6 T. Tsenov 8 A. Lior 9 Bridgewater Systems 10 J. Korhonen 11 TeliaSonera 12 March 5, 2007 14 RADIUS Quality of Service Support 15 draft-tschofenig-radext-qos-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 6, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document describes an extension to the RADIUS protocol that 49 performs authentication, authorization, and accounting for Quality- 50 of-Service reservations. 52 The described extensions allow network elements to authenticate the 53 initiator of a reservation request (if desired), to ensure that the 54 reservation is authorized, and to account for established QoS 55 resources. 57 Flexibility is provided by offering support for different 58 authorization models and by decoupling specific QoS attributes 59 carried in the QoS signaling protocol from the AAA protocol. This 60 document is the RADIUS complement to the DIAMETER QoS application. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. RADIUS functional considerations . . . . . . . . . . . . . . . 7 68 5. Authorization and QoS parameter provision . . . . . . . . . . 8 69 5.1. QoS enabled initial access authentication and 70 authorization . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Mid-Session QoS authorization . . . . . . . . . . . . . . 9 72 5.2.1. Client-side initiated QoS 73 authorization/re-authorization . . . . . . . . . . . . 9 74 5.2.2. Server-side initiated Re-Authorization . . . . . . . . 9 75 5.3. Session Termination . . . . . . . . . . . . . . . . . . . 10 76 5.3.1. Client-side initiated session termination . . . . . . 10 77 5.3.2. Server-side initiated session termination . . . . . . 10 78 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7.1. QoS-Resources . . . . . . . . . . . . . . . . . . . . . . 12 81 7.2. ExtendedQoSFilterRule . . . . . . . . . . . . . . . . . . 13 82 7.3. QoS-Parameter . . . . . . . . . . . . . . . . . . . . . . 15 83 7.4. QoS-Flow-State . . . . . . . . . . . . . . . . . . . . . . 17 84 7.5. Authorization Objects . . . . . . . . . . . . . . . . . . 18 85 8. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 20 86 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 9.1. RADIUS authorization of a QoS signaling reservation 88 request . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 9.2. RADIUS authentication, authorization and management of 90 a QoS-enabled access session . . . . . . . . . . . . . . . 23 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 93 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 94 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 95 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29 96 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 98 Intellectual Property and Copyright Statements . . . . . . . . . . 32 100 1. Introduction 102 To meet the quality-of-service needs of applications such as voice- 103 over-IP, it will often be necessary to explicitly request resources 104 from the network. This will allow the network to identify packets 105 belonging to these application flows and ensure that bandwidth, 106 delay, and error rate requirements are met. 108 This document is a complement to the ongoing work of the DIAMETER QoS 109 application described in [6]. It describes RADIUS protocol 110 extensions supporting AAA in an environment where better than best 111 effort Quality of Service is desired. The suggested extensions to 112 the RFC 2865 [1], RFC 2866 [7], RFC 2869 [8] and RFC 3576 [9] satisfy 113 the requirements defined in [10]. 115 Disclaimer: The content of this document will be aligned with the 116 ongoing QoS work in the DIME working group. Additionally, the 117 description of the data traffic that is experiencing the QoS 118 treatment will be aligned with the [11]. Hence, the content of the 119 attributes presented in this document are subject to change. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC-2119 [2]. 127 3. Goals 129 This document has a few ambitious goals, namely: 131 o Decouple the QoS signaling protocol (such as NSIS, RSVP or link 132 layer QoS signaling protocols) from the AAA protocol. This goal 133 is accomplished with the help of a generic QoS description, the 134 QSPEC object. 136 o Support for different scenarios that demand authorization for QoS 137 reservations. The impact is to provide flexibility with regard to 138 the entities that trigger the QoS reservation, the QoS parameters 139 that need to be provided to the RADIUS server for authorization, 140 the granularity of the QoS reservation (e.g., for an individual 141 application flow, for an aggregate). 143 4. RADIUS functional considerations 145 Being a value-added service, QoS provisioning SHOULD go along with 146 explicit authorization, accounting and control over the QoS-featured 147 user session. Specifically, the management of the authorized session 148 with Session-Timeout(27) and Termination-Action(29) attributes raises 149 a number of issues, identified in [12]. The solution presented in 150 this document aims to allow explicit control by the RADIUS server 151 (Authorizing entity) over the authorization session and its 152 parameters. In addition, it aims to support flexible deployment 153 scenarios of QoS authorization and parameter provisioning by 154 Authorization entities, which know the user and its subscription 155 profile (Home AAA server) or can provide authorization for a session 156 requested by the user (Application server). QoS authorization and 157 parameter provisioning MAY be incorporated into initial 158 authentication and authorization RADIUS exchange or MAY be triggered 159 at a later moment by a reception of a QoS signalling message. 161 5. Authorization and QoS parameter provision 163 5.1. QoS enabled initial access authentication and authorization 165 QoS enabled RADIUS client (NAS) initiates the authentication and 166 authorization process by sending a RADIUS Access-Request to the 167 user's Home AAA server. In addition to authentication related 168 attributes, it includes the QSPEC(TBD) attribute, which MAY specify 169 the QoS-Model [13] supported by the NAS and description of the 170 currently available QoS resources or description of the QoS 171 explicitly requested by the user. In the second case, additional 172 session and flow identification information MIGHT be included 173 together with the identity of the QoS authorizing application server. 175 If the authentication process involves multiple Access-Requests (as 176 in EAP), the RADIUS client MUST include the QSPEC(TBD) attribute and 177 any additional QoS-authorization related information in at least the 178 last Access-Request of the authentication process. 180 The Home AAA server receives the Access-Request message and 181 authenticates the user. Based on the user profile it determines the 182 subscription QoS parameters and includes them into the QSPEC(TBD) 183 attribute of the Access-Accept message. 185 In case that the QoS authorization MUST be done by an Application 186 server, which identity is included into the Access-Request message, 187 the Home server forwards the Access-Request to the Application 188 server. The Access-Request will contain the QSPEC(TBD) attribute and 189 session identification information. Upon successful authorization, 190 the Application server generates an Access-Accept containing the 191 QSPEC(TBD) attribute, flow identification information and optionally 192 bearer gating information. 194 The QSPEC attribute returned to the client SHOULD contain the 195 duration of the QoS enabled session. 197 If the authentication or authorization of the user is not successful, 198 the Home AAA server or the application server sends back an Access- 199 Reject message containing Reply-Message(18) attribute with the reason 200 for rejection. 202 When the QoS authorization exchange completes successfully, a RADIUS 203 Accounting session SHOULD start for reporting accounting information. 204 Accounting information is reported as described in [7] and [8]. Loss 205 of bearer information is reported using Access-Request message as 206 specified in the following section. 208 5.2. Mid-Session QoS authorization 210 5.2.1. Client-side initiated QoS authorization/re-authorization 212 Two types of QoS-related events MIGHT initiate Authorize-Only Access- 213 Request messages - reception of a QoS signaling message or expiration 214 of authorization lifetime of ongoing QoS-enabled session. In both 215 cases, the RADIUS client sends an Access-Request with Service-Type(6) 216 attribute set to a value of "Authorize-Only", QSPEC(TBD) attribute 217 and session and flow identification information. The QSPEC(TBD) 218 attribute includes description of new QoS parameters explicitly 219 required by the user or the QoS parameters that SHOULD be re- 220 authorized. Session and flow (only in the re-authorization case) 221 identification information SHOULD be the same as those used during 222 the initial Access-Request. For example, if the User-Name(1) 223 attribute was used in the initial Access-Request it MUST be included, 224 especially if the User-Name(1) attribute is used to route the Access- 225 Request to the Home RADIUS server. 227 The "Authorize-ONLY" Access-Request MUST NOT include either User 228 Password(2) or a CHAP Password(3). In order to protect the RADIUS 229 message, the RADIUS client MUST include the Message-Authenticator(80) 230 attribute. The RADIUS client will compute the value for the Message- 231 Authenticator(80) based on [8]. 233 The RADIUS server processes the information, including the 234 verification of the Message-Authenticator(80) as per [8], and upon 235 successful authorization it responds with a RADIUS Access-Accept 236 message. It contains the Service-Type(6) attribute with value 237 "Authorize-ONLY", the QSPEC(TBD) attribute, flow identification 238 information and optionally bearer gating information. The QSPEC(TBD) 239 attribute returned to the client SHOULD contain the new duration of 240 the QoS enabled session. In case of unsuccessful authorization an 241 Access-Reject message is sent, containing the Reply-Message(18) 242 attribute with the reason of rejection. 244 In case that an Application server MUST be contacted for the QoS 245 authorization, the Home server forwards the Access-Request to the 246 indicated Application server, which processes the QoS authorization 247 request. 249 5.2.2. Server-side initiated Re-Authorization 251 In order to take advantage of the dynamic authorization capabilities 252 of RADIUS as defined in [9], the Authorization entity (Home or 253 Application server) MUST be sure that the RADIUS client supports them 254 too. An advertising approach proposed in [12] MIGHT be used.(TBD) 255 At any time during the QoS session the RADIUS server MAY send a 256 Change-of-Authorization (CoA) message with Service-Type(6) attribute 257 set to value "Authorize-ONLY" and session and flow identification 258 information. The RADIUS client MUST respond with a Change-of- 259 Authorization NACK message with Service-Type(6) attribute with value 260 "Authorize-ONLY" and Error-Cause(101) attribute set to value 261 "Request-Initiated". The RADIUS client MUST then send an Access- 262 Request containing Service-Type(6) attribute with value "Authorize- 263 ONLY", QSPEC(TBD) attribute, session and flow identification 264 information. This approach is compatible with the DIAMETER re- 265 authorization procedure and is defined in RFC 3576 [9]. Furthermore, 266 the "State" attribute SHOULD be used as specified in RFC 3576 [9]. 268 5.3. Session Termination 270 5.3.1. Client-side initiated session termination 272 Service session MAY be related to a particular authorized QoS- 273 provisioned data flow. In this case, session termination MAY be 274 caused by a QoS signaling tear down message or loss of bearer report. 275 In another scenario the service session is a QoS enabled access 276 session, which can handle authorization of several QoS-provisioned 277 user's data flows. In this case session termination MAY be caused by 278 user log-off. 280 A RADIUS client indicates session termination by sending an 281 Accounting-Request message with Acc-Status-Type(40) attribute set to 282 "Stop" value and final QoS related accounting records(TBD). 284 5.3.2. Server-side initiated session termination 286 At anytime during a session the Authorizing Server may send a 287 Disconnect message to terminate the session. This capability is 288 described in detail in RFC 3576 [9]. The RADIUS server sends a 289 Disconnect message that MUST contain identifiers that uniquely 290 determine the subscriber's session and the RADIUS client serving that 291 session and Service-Type(6) attribute with value "Authorize-ONLY". 293 If the RADIUS client receives a Disconnect message, it MUST respond 294 with the Disconnect-NACK message with Service-Type(6) attribute with 295 value "Authorize-ONLY" and Error-Cause(101) attribute with value 296 "Request-Initiated". If it is able to terminate the session it will 297 send Access-Request message with Service-Type(6) attribute with value 298 "Authorize-ONLY" and attributes for session termination. This 299 message flow is required for compatibility with DIAMETER protocol. 300 Also the State(24) attribute SHOULD be used as specified in RFC 3576 301 [9]. 303 6. Accounting 305 Application of the RADIUS protocol for QoS authorization presented in 306 this document use RADIUS Accounting as defined in the RFC2865 [1], 307 RFC2866 [7] and RFC2869 [8]. The attributes containing a QoS 308 description and flow identification (see Section 7) are used in the 309 accounting session for reporting the status and parameters of the 310 provided QoS. The definition of new accounting attributes may be 311 necessary. This aspect is for further study. 313 After a successful QoS authorization the RADIUS client starts the 314 corresponding accounting session by sending the Accounting-Request 315 message. This message SHOULD contain necessary attributes to bind 316 the current accounting session to the reported QoS session. 317 Class(25) and Acc-Session-ID(44) attributes SHOULD be used according 318 to [1] and [7]. The RADIUS server responds with an Accounting- 319 Response message after successfully processing the Accounting-Request 320 message. The Accounting-Response message MAY contain instructions 321 for managing the accounting session, such as the Acct-Interim- 322 Interval(85) attribute. 324 After every successful re-authorization procedure the RADIUS client 325 SHOULD re-initiate accounting message exchange. 327 For indication of session termination the RADIUS client SHOULD 328 initiate a final exchange of accounting messages with the RADIUS 329 server. 331 7. Attributes 333 This section defines a QoS-Resource attribute that which consists 334 ofthree categories of attributes: 336 o A QoS filter rule for packet classification 338 o QoS parameters describing requested/authorized QoS 340 o Enumerated value stating when and how to apply the QoS-parameters 341 to a flow. 343 o Attributes required to carry authorization information (e.g., 344 authorization tokens as specified in [3]) 346 7.1. QoS-Resources 348 The QoS-Resources attribute is a single group attribute that can be 349 sent in RADIUS messages to Authenticate, Authorize and provide 350 Accounting information for QoS parameters of Flows. 352 0 1 2 3 353 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Extended-QoS-Filter | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Extended-QoS-Filter | SUB-TYPE 2 | LENGTH | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | QoS-Parameter | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | QoS-parameter | SUB-TYPE 3 | LENGTH | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | QoS-Flow-State | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | QoS-Flow-State | SUB-TYPE 4 | LENGTH | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Authorization-token | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Type: Value of QoS-Resources 373 Length: variable, greater than 8 375 String: The String value MUST be encoded as follows: 377 Sub-Type (=1): Sub-Type for Extended-QoS-Filter 379 Length : variable, greater than 8 381 String : 383 The Extended-QoS-Filter rule is a string type defined in 384 Section 7.2 386 Sub-Type (=2): Sub-Type for QoS-Parameter 388 Length : variable, greater than 8 390 String : 392 The QoS-Parameter is a string type defined in Section 7.3 394 Sub-Type (=3): Sub-Type for QoS-Flow-State 396 Length : variable, greater than 8 398 String : 400 The QoS-Flow-State rule is a string type defined in Section 7.4 402 Sub-Type (=4): Sub-Type for Authorization-Token 404 Length : variable, greater than 8 406 String : 408 The Authorization-Token is a string type defined in Section 7.5 410 7.2. ExtendedQoSFilterRule 412 The Extended QoS filter rule parameter is based on [4] and is used as 413 a packet classifier. 415 0 1 2 3 416 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Extended-QoS-Filter-Value | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Extended-QoS-Filter-Value | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Type: Value of Extended-QoS-filter-Value 427 Length: variable, greater than 8 429 String: The String value uses the ASCII charset. It MUST follow the 430 format: 432 The ExtendedQoSFilterRule is an OctetString. It uses the ASCII 433 charset. The ExtendedQoSFilterRule MUST follow the format: 435 action dir proto from src to dst [options] 437 Labels Description 439 action Action associated with the packet treatment. 440 Basic actions are described in the IPFilterRule 441 and extended for usage with QoS treatment. 443 dir Direction of the packet follow the filter applies to. 444 A basic description can be found with the 445 IPFilterRule. Examples are in, out and both. 447 proto Protocol 448 A description can be found with the IPFilterRule. 450 src and dst
[ports] 451 A description can be found with the IPFilterRule. 453 flow-label IPv6 Flow Label 454 A description can be found in TBD. 456 dscp Diffserv Codepoints 457 A description can be found in TBD. 459 ipsec-spi IPsec Security Parameter Index (SPI) 460 A description can be found in TBD. 462 qos-id A unique id referencing the applicable QoS parameters 463 that need to be applied to the specified packets. 465 Rules for the appropriate direction are evaluated in order, with the 466 first matched rule terminating the evaluation. Each packet is 467 evaluated once. If no rule matches, the packet is treated as best 468 effort. An access device that is unable to interpret or apply a QoS 469 rule SHOULD NOT terminate the session. 471 7.3. QoS-Parameter 473 The generic QoS description is taken from [5] which aims to support 474 QoS parameters for all QoS reservations and is independent of a 475 specific QoS model (QOSM). The QoS-Parameter template format is 476 identified by a qoS-Id value and has QSPEC parameters in it. These 477 QSPEC parametrs are organized into QoS Control information, 478 Requested, Reserved, Available and Minimum objects. 480 QoS-Id and QSPEC parameters are are included as subtypes into the 481 QSPEC attribute. Subtypes not used are omitted in the message. 483 0 1 2 3 484 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | QoS-ID | SUB-TYPE 2 | LENGTH | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | TMOD Rate-1 [r] | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | SUB-TYPE 2 | LENGTH | TMOD Size-1 [b] | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | TMOD Size-1[b] | SUB-TYPE 2 | LENGTH | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Peak Data Rate-1 [p] | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | SUB-TYPE 2 | LENGTH | Minimum policed unit-1 [m] | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 |Minimum policed unit-1 [m] | SUB-TYPE 2 | LENGTH | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | TMOD Rate-2 [r] | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | SUB-TYPE 2 | LENGTH | TMOD Size-2 [b] | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | TMOD Size-2[b] | SUB-TYPE 2 | LENGTH | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Peak Data Rate-2 [p] | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | SUB-TYPE 2 | LENGTH | Minimum policed unit-2 [m] | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 |Minimum policed unit-2 [m] | SUB-TYPE 2 | LENGTH | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Path Latency | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | SUB-TYPE 2 | LENGTH | Path Jitter STAT1 | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Path Jitter STAT1 | SUB-TYPE 2 | LENGTH | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Path Jitter STAT2 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | SUB-TYPE 2 | LENGTH | Path Jitter STAT3 | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 |Path Jitter STAT3 | SUB-TYPE 2 | LENGTH | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |Path Jitter STAT4 | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | SUB-TYPE 2 | LENGTH | Path Packet Loss Ratio | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Path Packet Loss Ratio | SUB-TYPE 2 | LENGTH | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Path Packet Error Ratio | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | SUB-TYPE 2 | LENGTH | Slack Term | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 |Slack Term | SUB-TYPE 2 | LENGTH | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 |Preemption prioroty | SUB-TYPE 2 | LENGTH | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |Defending priority | SUB-TYPE 2 | LENGTH | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |Admission Priority | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | SUB-TYPE 2 | LENGTH | RPH Namespace | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | RPH Priority | SUB-TYPE 2 | LENGTH | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Excess Treatment Parameter | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | SUB-TYPE 2 | LENGTH | PHB Class Parameter | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | PHB Class Parameter | SUB-TYPE 2 | LENGTH | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |DSTE Class Type Parameter | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | SUB-TYPE 2 | LENGTH | Y.1541 QoS Class | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Y.1541 QoS Class | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 The above-mentioned attributes are defined in [5] and the list of 562 parameters mentioned SHOULD be updated according to [5]. 564 7.4. QoS-Flow-State 566 The QoS-Flow-State gives an indication by the Authorizing entity as 567 to how the flow MUST be treated. When included in an Access-Request 568 message, it contains an action to be performed on the state of the 569 flow to which the message applies. It is of type Enumerated. 571 TBD 572 0 1 2 3 573 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | QoS-flow-State | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Type: Enumerated 582 Length : Length of QoS-Flow-State attribute (= 4 octets) 584 QoS-Flow-State: 586 0 Open - Enable the transport plane service, for which 587 the signaling has been performed. 588 1 Close - Disable the transport plane service 589 2 Maintain - Do not alter the current state (enabled/disabled) 590 of the transport plane service. 592 The QoS-Flow-State is optional. When not included in a Access- 593 Accept response, the default behavior is to immediately allow the 594 flow of packets (Open). 596 The behavior of Close (0) for the QoS-Flow-State refers to the 597 case where a QoS reservation exists but it is not activated and 598 therefore not charged. For time-based charging the time interval 599 where the gate is closed will not be included of the chargeable 600 time interval. The QoS model might give some indication whether 601 an established QoS reservation needs to be freed or needs to be 602 removed only if not enough resources are available. 604 7.5. Authorization Objects 606 Depending on the deployment, different attributes MAY be used as an 607 input for computing the QoS authorization decision by the Authorizing 608 entity. In addition to the credentials of the end host, requesting 609 QoS reservation (e.g., User-Name(1) attribute), an authorization 610 token MAY be used. This occurs in a deployment scenario, where the 611 QoS parameters are negotiated as part of an application layer 612 signaling exchange and where the authorization decision at this 613 application layer exchange needs to be associated with the 614 authorization of the QoS reservation of the QoS signaling exchange. 615 The QoS-Authorization-Data attribute is designated to encapsulate 616 such information. 618 0 1 2 3 619 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | TYPE | LENGTH | SUB-TYPE 1 | LENGTH | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Authorization-Token | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Type : Value of QoS-Authorization-Data 628 Length: variable, greater than 8 630 String: The String value MUST be encoded as follows: 632 Sub-Type (=1): Authorization-Token 634 Length : Length of Authorization-Token attribute 636 Authorization-Token: 638 The Authorization-Token sub-attribute is a container that 639 encapsulates an authorization token received via the QoS signaling 640 message typically sent by the end host. The token is generated by 641 the Authorizing entity during the application layer signaling 642 exchange and identifies the application service session, for which 643 the QoS reservation request applies. A possible structure for the 644 authorization token is proposed in context of RSVP [3] or using 645 SAML as outlined in [14] and [15]. The structure of the token is 646 considered to be out of the scope for this document. 648 8. Diameter RADIUS Interoperability 650 In deployments where RADIUS clients communicate with DIAMETER servers 651 or DIAMETER clients communicate with RADIUS servers then a 652 translation agent will be deployed and operate. The DIAMETER-QoS 653 specification [6] provides a natural candidate for mapping the RADIUS 654 QoS related AVPs to DIAMETER AVPs and messages. 656 9. Examples 658 The following diagrams show RADIUS protocol interactions for 659 different scenarios and deployment architectures. 661 9.1. RADIUS authorization of a QoS signaling reservation request 662 RADIUS RADIUS 663 Client Server 664 -----------> | | 665 QoS | Access-Request/UserID, QSPEC/ | 666 reservation |----------------------------------------------->| 667 request | | 668 | Access-Accept/QSPEC/ | 669 |<-----------------------------------------------| 670 | | 671 Start |Accounting-Request/Start, Acc-Session-ID.../ | 672 Accounting |----------------------------------------------->| 673 | Accounting-Response/...Acc-Interim-Period.../ | 674 |<-----------------------------------------------| 675 | | 676 Authorization| | 677 LifeTime | | 678 Expires: | | 679 Re- | Access-Request/Auth-ONLY, UserID, QSPEC/ | 680 Authorization|----------------------------------------------->| 681 | Access-Accept/ Auth-ONLY, QSPEC/ | 682 |<-----------------------------------------------| 683 | Accounting-Request/Interim, Acc-Session-ID./ | 684 |----------------------------------------------->| 685 | Accounting-Response/...Acc-Interim-Period.../ | 686 |<-----------------------------------------------| 687 ..................... 688 | Session 689 | Termination 690 | initiated 691 | by 692 | server 693 | Disconnect-Request/Auth-ONLY, .../ <------ 694 |<-----------------------------------------------| 695 | Disconnect-NACK/Auth-ONLY,"Request-Initiated"/ | 696 |----------------------------------------------->| 697 | Access-Request/Auth-ONLY,... | 698 | Acc-Terminate-Cause="Admin-Reset"/| 699 |----------------------------------------------->| 700 | Access-Accept | 701 |<-----------------------------------------------| 702 Accounting | Accounting-Request/Final,Acc-Session-ID./ | 703 end |----------------------------------------------->| 704 | Accounting-Response /Final,.../ | 705 |<-----------------------------------------------| 707 This example shows the protocol exchange between the RADIUS client 708 and the RADIUS server. An incoming QoS reservation request received 709 at the QoS policy aware node (i.e., RADIUS client) invokes the 710 transmission of a Access-Request message (AR) to the RADIUS server. 711 This message contains the requested QoS resources in a QSPEC 712 attribute along with user identification and authentication 713 information. After the request is successfully authenticated and 714 authorized, the RADIUS server replies with a Access-Accept message 715 (AA), which grants a reservation for a certain amount of resources 716 (as included in the QSPEC attribute). After the successful exchange 717 of the AR/AA messages, the RADIUS client starts an accounting session 718 by sending an Accounting-Request message. The server replies with an 719 Accounting-Response message that MAY include instructions for further 720 handling of the accounting session, such as the Acc-Interim-Period 721 attribute. 723 The client-side re-authorization caused by expiration of the 724 authorization lifetime initiates an Authorize-ONLY Access-Request / 725 Access-Accept message exchange. After a successful re-authorization 726 an Accounting-Request message SHOULD be sent to indicate the new 727 authorization parameters. The server replies with an Accounting- 728 Response message. 730 In this example, the RADIUS server initiates a session termination. 731 It therefore sends a Disconnect-Request message. The client responds 732 with a Disconnect-NACK message and sends an AR message indicating the 733 termination cause. The server replies to the AR message with an AA 734 message. After receiving the AA message sent by the server, the 735 client sends remaining accounting information with the Accounting- 736 Request message. The server replies with the Accounting-Response 737 message. 739 9.2. RADIUS authentication, authorization and management of a QoS- 740 enabled access session 742 QoS enabled NAS Home 743 RADIUS client RADIUS server 744 | | 745 | Access-Request/....QSPEC(QoS Available) .../ | 746 v----------------------------------------------->| 747 * | 748 * Multiple | 749 Authentication *<==============================================>| 750 process * Access-Request/Access-Challenge Exchange | 751 * | 752 * | 753 Access granted; * Access-Accept/...QSPEC(user-profile QoS).../| 754 install QoS v<-----------------------------------------------| 755 | | 756 | Accounting-Request/...QSPEC(installed QoS)../ | 757 |----------------------------------------------->| 758 | Accounting-Response/.../ | 759 |<-----------------------------------------------| 760 | | 761 | | 762 QoS-Request | Access-Request/Auth-ONLY, QSPEC, QoS-Flow-ID/ | 763 --------------->|----------------------------------------------->| 764 | Access-Response/Auth-ONLY, QSPEC, QoS-Flow-ID/| 765 QoS authorized; *<-----------------------------------------------| 766 install QoS for | | 767 QoS-Flow-ID | | 768 | Accounting-Request/Interim,.../ | 769 |----------------------------------------------->| 770 | Accounting-Response/.../ | 771 |<-----------------------------------------------| 772 .............................................................. 773 | | 774 * | 775 QoS-Flow-ID authz.lifetime expires | 776 Delete QoS for QoS-Flow-ID | 777 | | 778 | Accounting-Request/Interim,.../ | 779 |----------------------------------------------->| 780 | Accounting-Response/.../ | 781 |<-----------------------------------------------| 782 .............................................................. 783 | | 784 | CoA-Request /Auth-ONLY,QSPEC.../ | 785 |<-----------------------------------------------| 786 | CoA-NACK/Auth-ONLY,"Request-Initiated"/ | 787 |----------------------------------------------->| 788 | Access-Request/Auth-ONLY,QSPEC.../ | 789 |----------------------------------------------->| 790 | Access-Accept/Auth-ONLY,QSPEC(New QoS).../ | 791 Install QoS *<-----------------------------------------------| 792 | | 793 | Accounting-Request/...QSPEC(installed QoS)../ | 794 |----------------------------------------------->| 795 | Accounting-Response/.../ | 796 |<-----------------------------------------------| 798 This example shows the interaction between a QoS enabled NAS and a 799 Home AAA server. This example aims to show a QoS-enabled access 800 session. The NAS performs authorization of the QoS-provisioned flows 801 as part of the user's access session. 803 The NAS performs initial authentication and authorization of the end 804 user for an access session. This process MAY take several Access- 805 Request / Access-Challenge message exchanges. By including the QSPEC 806 attribute, the RADIUS server provides a description of the QoS 807 parameters of the user access session. The NAS allocates certain QoS 808 resources according to the QoS parameters provided by the RADIUS 809 server and currently available QoS resources. The NAS initiates an 810 accounting session by sending the Accounting-Request message in which 811 it reports the actually allocated QoS resources for the access 812 session. The server replies with an Accounting-Response message that 813 MAY include instructions for further handling of the accounting 814 session, such as the Acc-Interim-Period attribute. 816 Later, when the NAS intercepts a QoS signaling message sent from the 817 end host an Authorize-ONLY Access-Request message is triggered and 818 sent to the RADIUS server. It includes the description of the 819 requested QoS resources in the QSPEC attribute. Optionally, an 820 identifier of the flow that should receive the requested QoS 821 treatment is included into the Access-Request message. The RADIUS 822 server (in the user's home domain) validates the QoS request and 823 replies with Authorize-ONLY Access-Accept message. The message 824 includes a QSPEC attribute with description of the authorized QoS 825 parameters and the duration of authorization. An identifier of the 826 flow that should receive the requested QoS is also provided. The 827 RADIUS client will install a QoS reservation based on the provided 828 QoS parameters for that flow and sends an Accounting-Request message 829 reporting the new QoS session. The server replies with an 830 Accounting-Response message. 832 In this example, the authorization lifetime of the QoS-provisioned 833 flow expires. The NAS releases the reserved QoS resources allocated 834 for the flow when the authorization has expired. In addition, the 835 NAS sends an Accounting-Request message to the RADIUS server, 836 indicating the stop of QoS provisioning for the flow. 838 If the Home AAA server decides to change QoS parameters for the 839 user's access session it sends an Authorize-ONLY Change-of- 840 Authorization-Request message to the RADIUS client, identifying the 841 affected access session. The NAS replies with a CoA-NACK message 842 indicating that an Access-Request has to be generated. The 843 Authorize-ONLY Access-Request message contains the QSPEC attribute 844 with the QoS resources currently available at the NAS. The RADIUS 845 server replies with the Authorize-ONLY Access-Accept message with a 846 QSPEC attribute containing the new QoS parameters that should be 847 provided to the user's session. The NAS allocates certain QoS 848 resources according to the QoS parameters provided by the RADIUS 849 server and the currently available QoS resources. It sends an 850 Accounting-Request message in which it reports the actual allocated 851 QoS resources for the access session. The server replies with an 852 Accounting-Response message. 854 10. IANA Considerations 856 TBD 858 11. Security Considerations 860 For this extension to RADIUS protocol the security considerations 861 defined in RFC2865 [1], RFC2866 [7], RFC2869 [8] and RFC3576 [9] are 862 applicable. Furthermore, the security of the QoS signaling protocol 863 and the QoS authorization framework must be considered in the 864 evaluation of the security properties. 866 [Editor's Note: A more detailed treatment will be provided in a 867 future document version.] 869 12. Acknowledgments 871 We would like to thank Pete McCann and Franck Alfano for their work 872 on the Diameter QoS application. 874 13. References 876 13.1. Normative References 878 [1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 879 Authentication Dial In User Service (RADIUS)", RFC 2865, 880 June 2000. 882 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 883 Levels", March 1997. 885 [3] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session 886 Authorization Policy Element", RFC 3520, April 2003. 888 [4] Zorn, G., McCann, P., Tschofenig, H., Tsou, T., and A. Doria, 889 "Diameter Quality of Service Application", 890 draft-ietf-dime-diameter-qos-00.txt (work in progress), 891 February 2006. 893 [5] Korhonen, J. and H. Tschofenig, "Quality of Service Parameters 894 for RADIUS and Diameter", 895 draft-korhonen-dime-qos-parameters-00.txt (work in progress), 896 February 2006. 898 13.2. Informative References 900 [6] Alfano, F., "Diameter Quality of Service Application", 901 draft-tschofenig-dime-diameter-qos-01 (work in progress), 902 October 2006. 904 [7] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 906 [8] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", 907 RFC 2869, June 2000. 909 [9] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, 910 "Dynamic Authorization Extensions to Remote Authentication Dial 911 In User Service (RADIUS)", RFC 3576, July 2003. 913 [10] Alfano, F., "Requirements for a QoS AAA Protocol", 914 draft-alfano-aaa-qosreq-01 (work in progress), October 2003. 916 [11] Congdon, P., "RADIUS Filter Rule Attribute", 917 draft-ietf-radext-filter-08 (work in progress), January 2007. 919 [12] Lior, A., "Prepaid extensions to Remote Authentication Dial-In 920 User Service (RADIUS)", draft-lior-radius-prepaid-extensions-11 921 (work in progress), June 2006. 923 [13] Ash, J., "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-15 924 (work in progress), February 2007. 926 [14] Peterson, J., "Trait-based Authorization Requirements for the 927 Session Initiation Protocol (SIP)", 928 draft-ietf-sipping-trait-authz-02 (work in progress), 929 January 2006. 931 [15] Tschofenig, H., "SIP SAML Profile and Binding", 932 draft-ietf-sip-saml-01 (work in progress), October 2006. 934 Authors' Addresses 936 Hannes Tschofenig 937 Siemens 938 Otto-Hahn-Ring 6 939 Munich, Bavaria 81739 940 Germany 942 Email: Hannes.Tschofenig@siemens.com 943 URI: http://www.tschofenig.com 945 Allison Mankin 946 1025 Vermont Avenue 947 Washington, DC 20005 948 US 950 Phone: +1 301-728-7199 (mobile) 951 Email: mankin@psg.com 952 URI: http://www.psg.com/~mankin/ 954 Tseno Tsenov 955 Sofia, 956 Bulgaria 958 Email: tseno.tsenov@mytum.de 960 Avi Lior 961 Bridgewater Systems Corporation 962 303 Terry Fox Drive 963 Ottawa, Ontario K2K 3J1 964 Canada 966 Phone: +1 613-591-6655 967 Email: avi@bridgewatersystems.com 969 Jouni Korhonen 970 TeliaSonera 971 Teollisuuskatu 13 972 Sonera FIN-00051 973 Finland 975 Email: jouni.korhonen@teliasonera.com 977 Full Copyright Statement 979 Copyright (C) The IETF Trust (2007). 981 This document is subject to the rights, licenses and restrictions 982 contained in BCP 78, and except as set forth therein, the authors 983 retain all their rights. 985 This document and the information contained herein are provided on an 986 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 987 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 988 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 989 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 990 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 991 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 993 Intellectual Property 995 The IETF takes no position regarding the validity or scope of any 996 Intellectual Property Rights or other rights that might be claimed to 997 pertain to the implementation or use of the technology described in 998 this document or the extent to which any license under such rights 999 might or might not be available; nor does it represent that it has 1000 made any independent effort to identify any such rights. Information 1001 on the procedures with respect to rights in RFC documents can be 1002 found in BCP 78 and BCP 79. 1004 Copies of IPR disclosures made to the IETF Secretariat and any 1005 assurances of licenses to be made available, or the result of an 1006 attempt made to obtain a general license or permission for the use of 1007 such proprietary rights by implementers or users of this 1008 specification can be obtained from the IETF on-line IPR repository at 1009 http://www.ietf.org/ipr. 1011 The IETF invites any interested party to bring to its attention any 1012 copyrights, patents or patent applications, or other proprietary 1013 rights that may cover technology that may be required to implement 1014 this standard. Please address the information to the IETF at 1015 ietf-ipr@ietf.org. 1017 Acknowledgment 1019 Funding for the RFC Editor function is provided by the IETF 1020 Administrative Support Activity (IASA).