idnits 2.17.1 draft-ietf-dime-extended-naptr-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3588]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3588, updated by this document, for RFC5378 checks: 2001-02-09) -- 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 (May 9, 2011) is 4729 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) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4006 (Obsoleted by RFC 8506) -- Possible downref: Non-RFC (?) normative reference: ref. 'WiMAX' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions M. Jones 3 (DIME) Bridgewater Systems 4 Internet-Draft J. Korhonen 5 Updates: 3588 (if approved) Nokia Siemens Networks 6 Intended status: Standards Track L. Morand 7 Expires: November 10, 2011 Orange Labs 8 May 9, 2011 10 Diameter S-NAPTR Usage 11 draft-ietf-dime-extended-naptr-08 13 Abstract 15 The Diameter base protocol specifies mechanisms whereby a given realm 16 may advertise Diameter nodes and the supported transport protocol. 17 However, these mechanisms do not reveal the Diameter applications 18 that each node supports. A peer outside the realm would have to 19 perform a Diameter capability exchange with every node until it 20 discovers one that supports the required application. This document 21 updates [RFC3588] and describes an improvement using an extended 22 format for the Straightforward-Naming Authority Pointer (S-NAPTR) 23 Application Service Tag that allows for discovery of the supported 24 applications without doing Diameter capability exchange beforehand. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 10, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Extended NAPTR Service Field Format . . . . . . . . . . . . . 3 69 3.1. IETF Standard Track Diameter Applications . . . . . . . . 4 70 3.2. Vendor-specific Diameter Applications . . . . . . . . . . 4 71 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 5 72 5. Extended NAPTR-based Diameter Peer Discovery . . . . . . . . . 5 73 6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 7 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. IETF Diameter Application Service Tags . . . . . . . . . . 7 76 7.2. 3GPP Diameter Application Service Tags . . . . . . . . . . 8 77 7.3. WiMAX Forum Diameter Application Service Tags . . . . . . 8 78 7.4. Vendor-Specific Diameter Application Service Tags . . . . 9 79 7.5. Diameter Application Protocol Tags . . . . . . . . . . . . 9 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 82 10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . . 10 83 11. Normative References . . . . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 The Diameter base protocol [RFC3588] specifies three mechanisms for 89 the Diameter peer discovery. One of these involves the Diameter 90 implementation performing a Naming Authority Pointer (NAPTR) query 91 [RFC3403] for a server in a particular realm. These NAPTR records 92 provide a mapping from a domain, to the SRV record [RFC2782] or 93 A/AAAA record [RFC1035][RFC3596] for contacting a server with the 94 specific transport protocol in the NAPTR services field. 96 The extended NAPTR usage for Diameter peer discovery defined by this 97 document is based on the Straightforward-NAPTR (S-NAPTR) Dynamic 98 Delegation Discovery System (DDDS) Application defined in [RFC3958]. 99 This document updates the Diameter peer discovery procedure described 100 in Section 11.6 of [RFC3588] and defines S-NAPTR Application Service 101 and Application Protocol Tag values that permit the discovery of 102 Diameter peers that support a specific Diameter application and 103 transport protocol. 105 2. Terminology 107 The Diameter base protocol specification (Section 1.4 of [RFC3588]) 108 and the Straightforward-NAPTR (S-NAPTR) DDDS application (section 2.1 109 in [RFC3958]) define the terminology used in this document. 111 3. Extended NAPTR Service Field Format 113 The NAPTR Service Field format defined by the S-NAPTR DDDS 114 application in [RFC3958] follows this Augmented Backus-Naur Form 115 (ABNF, [RFC5234]): 117 service-parms = [ [app-service] *(":" app-protocol)] 118 app-service = experimental-service / iana-registered-service 119 app-protocol = experimental-protocol / iana-registered-protocol 120 experimental-service = "x-" 1*30ALPHANUMSYM 121 experimental-protocol = "x-" 1*30ALPHANUMSYM 122 iana-registered-service = ALPHA *31ALPHANUMSYM 123 iana-registered-protocol = ALPHA *31ALPHANUMSYM 124 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 125 DIGIT = %x30-39 ; 0-9 126 SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." 127 ALPHANUMSYM = ALPHA / DIGIT / SYM 128 ; The app-service and app-protocol tags are limited to 32 129 ; characters and must start with an alphabetic character. 130 ; The service-parms are considered case-insensitive. 132 This specification refines the "iana-registered-service" tag 133 definition for the discovery of Diameter agents supporting a specific 134 Diameter application as defined below. 136 iana-registered-service = aaa-service / ALPHA *31ALPHANUMSYM 137 aaa-service = "aaa+ap" appln-id 138 appln-id = 1*DIGIT 139 ; Application identifier expressed as a 140 ; decimal integer. 142 This specification also refines the "iana-registered-protocol" tag 143 definition for the discovery of Diameter agents supporting a specific 144 Diameter transport protocol as defined below. 146 iana-registered-protocol = aaa-protocol / ALPHA *31ALPHANUMSYM 147 aaa-protocol = "diameter." aaa-transport 148 aaa-transport = "tcp" / "sctp" / "tls.tcp" 150 The maximum length of the NAPTR service field is 256 octets including 151 one octet length field (see Section 4.1 of RFC 3403 and Section 3.3 152 of [RFC1035]). 154 3.1. IETF Standard Track Diameter Applications 156 A Diameter agent MUST be capable of using the extended S-NAPTR 157 Application Service Tag for dynamic discovery of a Diameter agent 158 supporting Standard Track applications. Therefore, every IETF 159 Standard Track Diameter application MUST be associated with a "aaa- 160 service" tag formatted as defined in this specification and allocated 161 in accordance with the IANA policy (see Section 7). 163 For example, a NAPTR service field value of: 165 'aaa+ap6:diameter.sctp' 167 Means that the Diameter node in the SRV or A/AAAA record supports 168 the Diameter Session Initiation Protocol (SIP) Application ('6') 169 and SCTP as the transport protocol. 171 3.2. Vendor-specific Diameter Applications 173 S-NAPTR Application Service and Application Protocol Tag values can 174 also be used to discover Diameter peers that support a vendor- 175 specific Diameter application. In this case, the vendor-specific 176 Diameter application MUST be associated with a "aaa-service" tag 177 formatted as defined in this specification and allocated in 178 accordance with the IANA policy (see Section 7). 180 For example, a NAPTR service field value of: 182 'aaa+ap16777251:diameter.sctp' 184 Means that the Diameter node in the SRV or A/AAAA record supports 185 the Diameter 3GPP S6a Application ('16777251') and SCTP as the 186 transport protocol. 188 4. Backwards Compatibility 190 Domain Name System (DNS) administrators SHOULD also provision legacy 191 RFC 3588 style NAPTR records [RFC3403] in order to guarantee 192 backwards compatibility with legacy RFC 3588 compliant Diameter 193 peers. If the DNS administrator provisions both extended S-NAPTR 194 records as defined in this specification and legacy RFC 3588 NAPTR 195 records, then the extended S-NAPTR records MUST have higher priority 196 (e.g. lower order and/or preference values) than legacy NAPTR 197 records. 199 5. Extended NAPTR-based Diameter Peer Discovery 201 The Diameter Peer Discovery principles are described in Section 5.2 202 of [RFC3588]. This specification updates the NAPTR query procedure 203 in the Diameter peer discovery mechanism by allowing the querying 204 node to determine which applications are supported by resolved 205 Diameter peers. 207 The extended format NAPTR records provide a mapping from a domain to 208 the SRV record or A/AAAA record for contacting a server supporting a 209 specific transport protocol and Diameter application. The resource 210 record will contain an empty regular expression and a replacement 211 value, which is the SRV record or the A/AAAA record for that 212 particular transport protocol. 214 The assumption for this mechanism to work is that the DNS 215 administrator of the queried domain has first provisioned the DNS 216 with extended format NAPTR entries. The steps below replace the 217 NAPTR query procedure steps in Section 5.2 of [RFC3588]. 219 a. The Diameter implementation performs a NAPTR query for a server in 220 a particular realm. The Diameter implementation has to know in 221 advance which realm to look for a Diameter agent in and which 222 Application Identifier it is interested in. For example, the 223 realm could be deduced from the Network Access Identifier (NAI) in 224 the User-Name AVP or extracted from the Destination-Realm AVP. 226 b. If the returned NAPTR service fields contain entries formatted as 227 "aaa+apX:Y" where "X" indicates the Application Identifier and "Y" 228 indicates the supported transport protocol(s), the target realm 229 supports the extended format for NAPTR-based Diameter peer 230 discovery defined in this document. 232 If "X" contains the required Application Identifier and "Y" 233 matches a supported transport protocol, the Diameter 234 implementation resolves the "replacement" field entry to a 235 target host using the lookup method appropriate for the "flags" 236 field. 238 If "X" does not contain the required Application Identifier or 239 "Y" does not match a supported transport protocol, the Diameter 240 implementation abandons the peer discovery. 242 c. If the returned NAPTR service fields contain entries formatted as 243 "aaa+apX" where "X" indicates the Application Identifier, the 244 target realm supports the extended format for NAPTR-based Diameter 245 peer discovery defined in this document. 247 If "X" contains the required Application Identifier, the 248 Diameter implementation resolves the "replacement" field entry 249 to a target host using the lookup method appropriate for the 250 "flags" field and attempts to connect using all supported 251 transport protocols following the order specified in section 252 2.1 of [RFC3588]. 254 If "X" does not contain the required Application Identifier, 255 the Diameter implementation abandons the peer discovery. 257 d. If the returned NAPTR service fields contain entries formatted as 258 "aaa:X" where "X" indicates the supported transport protocol(s), 259 the target realm supports Diameter but does not support the 260 extended format for NAPTR-based Diameter peer discovery defined in 261 this document. 263 If "X" matches a supported transport protocol, the Diameter 264 implementation resolves the "replacement" field entry to a 265 target host using the lookup method appropriate for the "flags" 266 field. 268 e. If the returned NAPTR service fields contain entries formatted as 269 "aaa", the target realm supports Diameter but does not support the 270 extended format for NAPTR-based Diameter peer discovery defined in 271 this document. The Diameter implementation resolves the 272 "replacement" field entry to a target host using the lookup method 273 appropriate for the "flags" field and attempts to connect using 274 all supported transport protocols following the order specified in 275 section 2.1 of [RFC3588]. 277 f. If the target realm does not support NAPTR-based Diameter peer 278 discovery, the client proceeds with the next peer discovery 279 mechanism described in Section 5.2 of [RFC3588]. 281 6. Usage Guidelines 283 Diameter is a peer to peer protocol whereas most of the applications 284 that extend the base protocol behave like client/server applications. 285 The role of the peer is not advertised in the NAPTR tags and not even 286 communicated during Diameter capability negotiation (Capabilities- 287 Exchange-Request and Capabilities-Exchange-Answer message exchange). 288 For this reason, NAPTR-based Diameter peer discovery for an 289 application defining client/server roles should only be used by a 290 client to discover servers. 292 7. IANA Considerations 294 7.1. IETF Diameter Application Service Tags 296 IANA is requested to reserve a value of "aaa" for Diameter in the 297 S-NAPTR Application Service Tag registry created by [RFC3958]. IANA 298 is also requested to reserve the following S-NAPTR Application 299 Service Tags for existing IETF Diameter applications in the same 300 registry. 302 +------------------+----------------------------+ 303 | Tag | Diameter Application | 304 +------------------+----------------------------+ 305 | aaa+ap1 | NASREQ [RFC3588] | 306 | aaa+ap2 | Mobile IPv4 [RFC4004] | 307 | aaa+ap3 | Base Accounting [RFC3588] | 308 | aaa+ap4 | Credit Control [RFC4006] | 309 | aaa+ap5 | EAP [RFC4072] | 310 | aaa+ap6 | SIP [RFC4740] | 311 | aaa+ap7 | Mobile IPv6 IKE [RFC5778] | 312 | aaa+ap8 | Mobile IPv6 Auth [RFC5778] | 313 | aaa+ap9 | QoS [RFC5866] | 314 | aaa+ap4294967295 | Relay [RFC3588] | 315 +------------------+----------------------------+ 317 Future IETF Diameter applications MUST reserve the S-NAPTR 318 Application Service Tag corresponding to the allocated Diameter 319 Application ID as defined in Section 3. 321 7.2. 3GPP Diameter Application Service Tags 323 IANA is requested to reserve the following S-NAPTR Application 324 Service Tags for existing 3GPP Diameter applications in the S-NAPTR 325 Application Service Tag registry created by [RFC3958]. 327 +----------------+----------------------+ 328 | Tag | Diameter Application | 329 +----------------+----------------------+ 330 | aaa+ap16777250 | 3GPP STa [TS29.273] | 331 | aaa+ap16777251 | 3GPP S6a [TS29.272] | 332 | aaa+ap16777264 | 3GPP SWm [TS29.273] | 333 | aaa+ap16777267 | 3GPP S9 [TS29.215] | 334 +----------------+----------------------+ 336 Future 3GPP Diameter applications can reserve entries in the S-NAPTR 337 Application Service Tag registry created by [RFC3958] which 338 correspond to the allocated Diameter Application IDs as defined in 339 Section 3. 341 7.3. WiMAX Forum Diameter Application Service Tags 343 IANA is requested to reserve the following S-NAPTR Application 344 Service Tags for existing WiMAX Forum Diameter applications in the 345 S-NAPTR Application Service Tag registry created by [RFC3958]. 347 +----------------+--------------------------------------------------+ 348 | Tag | Diameter Application | 349 +----------------+--------------------------------------------------+ 350 | aaa+ap16777281 | WiMAX Network Access Authentication and | 351 | | Authorization Diameter Application (WNAAADA) | 352 | | [WiMAX] | 353 | aaa+ap16777282 | WiMAX Network Accounting Diameter Application | 354 | | (WNADA) [WiMAX] | 355 | aaa+ap16777283 | WiMAX MIP4 Diameter Application (WM4DA) [WiMAX] | 356 | aaa+ap16777284 | WiMAX MIP6 Diameter Application (WM6DA) [WiMAX] | 357 | aaa+ap16777285 | WiMAX DHCP Diameter Application (WDDA) [WiMAX] | 358 | aaa+ap16777286 | WiMAX Location Authentication Authorization | 359 | | Diameter Application (WLAADA) [WiMAX] | 360 | aaa+ap16777287 | WiMAX Policy and Charging Control R3 Policies | 361 | | Diameter Application (WiMAX PCC-R3-P) [WiMAX] | 362 | aaa+ap16777288 | WiMAX Policy and Charging Control R3 Offline | 363 | | Charging Diameter Application (WiMAX PCC-R3-OFC) | 364 | | [WiMAX] | 365 | aaa+ap16777289 | WiMAX Policy and Charging Control R3 Offline | 366 | | Charging Prime Diameter Application (WiMAX | 367 | | PCC-R3-OFC-PRIME) [WiMAX] | 368 | aaa+ap16777290 | WiMAX Policy and Charging Control R3 Online | 369 | | Charging Diameter Application (WiMAX PCC-R3-OC) | 370 | | [WiMAX] | 371 +----------------+--------------------------------------------------+ 373 Future WiMAX Forum Diameter applications can reserve entries in the 374 S-NAPTR Application Service Tag registry created by [RFC3958] which 375 correspond to the allocated Diameter Application IDs as defined in 376 Section 3. 378 7.4. Vendor-Specific Diameter Application Service Tags 380 Vendor-Specific Diameter Application IDs are allocated by IANA 381 according to the "First Come First Served" policy and do not require 382 an IETF specification. However, the S-NAPTR Application Service Tag 383 registry created by [RFC3958] defines a registration policy of 384 "Specification Required" with a further stipulation that the 385 "specification" is an RFC (of any category). If a Vendor-Specific 386 Diameter Application requires the functionality defined in this 387 document, an RFC of any category MUST be published which reserves the 388 S-NAPTR Application Service Tag corresponding to the Vendor-Specific 389 Diameter Application ID as defined in Section 3. 391 7.5. Diameter Application Protocol Tags 393 IANA is requested to reserve the following S-NAPTR Application 394 Protocol Tags for the Diameter transport protocols in the S-NAPTR 395 Application Protocol Tag registry created by [RFC3958]. 397 +------------------+----------+ 398 | Tag | Protocol | 399 +------------------+----------+ 400 | diameter.tcp | TCP | 401 | diameter.sctp | SCTP | 402 | diameter.tls.tcp | TLS/TCP | 403 +------------------+----------+ 405 8. Security Considerations 407 This document specifies an enhancement to RFC 3588 Diameter base 408 protocol defined NAPTR service field format and also modifications to 409 the NAPTR processing logic defined. The enhancements and 410 modifications are based on the S-NAPTR, which is actually a 411 simplification of the NAPTR, and therefore the same security 412 considerations described in RFC 3588 are applicable to this document. 413 No further extensions are required beyond the security mechanisms 414 offered by RFC 3588. However, a malicious host doing S-NAPTR queries 415 learns applications supported by Diameter agents in a certain realm 416 faster, which might help the malicious host to scan potential targets 417 for an attack more efficiently when some applications have known 418 vulnerabilities. 420 9. Acknowledgments 422 We would like to thank Glen Zorn, Avi Lior, Itsuma Tanaka, Lionel 423 Morand and Sebastien Decugis for their comprehensive review comments. 425 10. Editor's Notes 427 This section to be removed prior to publication. 429 This draft updates sections of RFC3588 that are also being updated by 430 RFC3588bis. At the time this draft was started, it was uncertain 431 whether RFC3588bis would be published first. The authors of this 432 draft decided to proceed optimistically assuming this draft would be 433 published first with the understanding that minor updates are 434 required if this is not the case. 436 The application-neutral aspects of Diameter S-NAPTR usage (e.g "aaa: 437 diameter.sctp") were also contributed to RFC3588bis to ensure that it 438 would be functionally complete if it got published first and this 439 draft would come along later to add the application-specific S-NAPTR 440 entries (e.g."aaa+ap5:diameter.sctp"). 442 Depending on the publication order, the S-NAPTR Application Service 443 Tag registry value of "aaa" and the S-NAPTR Application Protocol Tags 444 values ("diameter.tcp"/"diameter.sctp"/"diameter.tls.tcp") will need 445 to be removed either from this draft or RFC3588bis. 447 11. Normative References 449 [RFC1035] Mockapetris, P., "Domain names - implementation and 450 specification", STD 13, RFC 1035, November 1987. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 456 specifying the location of services (DNS SRV)", RFC 2782, 457 February 2000. 459 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 460 Part Three: The Domain Name System (DNS) Database", 461 RFC 3403, October 2002. 463 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 464 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 466 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 467 "DNS Extensions to Support IP Version 6", RFC 3596, 468 October 2003. 470 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 471 Service Location Using SRV RRs and the Dynamic Delegation 472 Discovery Service (DDDS)", RFC 3958, January 2005. 474 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 475 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 476 August 2005. 478 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 479 Loughney, "Diameter Credit-Control Application", RFC 4006, 480 August 2005. 482 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 483 Authentication Protocol (EAP) Application", RFC 4072, 484 August 2005. 486 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 487 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 488 Initiation Protocol (SIP) Application", RFC 4740, 489 November 2006. 491 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 492 Specifications: ABNF", STD 68, RFC 5234, January 2008. 494 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., 495 and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home 496 Agent to Diameter Server Interaction", RFC 5778, 497 February 2010. 499 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 500 and G. Zorn, "Diameter Quality-of-Service Application", 501 RFC 5866, May 2010. 503 [TS29.215] 504 3rd Generation Partnership Project, "3GPP TS 29.215; 505 Technical Specification Group Core Network and Terminals; 506 Policy and Charging Control (PCC) over S9 reference point; 507 Stage 3 (Release 8)", 508 . 510 [TS29.272] 511 3rd Generation Partnership Project, "3GPP TS 29.272; 512 Technical Specification Group Core Network and Terminals; 513 Evolved Packet System; Mobility Management Entity (MME) 514 and Serving GPRS Support Node (SGSN) Related Interfaces 515 Based on Diameter Protocol (Release 8)", 516 . 518 [TS29.273] 519 3rd Generation Partnership Project, "3GPP TS 29.273; 520 Technical Specification Group Core Network and Terminals; 521 Evolved Packet System; 3GPP EPS AAA interfaces (Release 522 8)", . 524 [WiMAX] WiMAX Forum, "WiMAX Release 1.5", . 527 Authors' Addresses 529 Mark Jones 530 Bridgewater Systems 532 Email: mark@azu.ca 534 Jouni Korhonen 535 Nokia Siemens Networks 537 Email: jouni.nospam@gmail.com 539 Lionel Morand 540 Orange Labs 542 Email: lionel.morand@orange-ftgroup.com