idnits 2.17.1 draft-ietf-dime-app-design-guide-08.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 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 711. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 24, 2008) is 5625 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'TBD' on line 230 == Unused Reference: '8' is defined on line 604, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 608, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 611, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 616, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-dime-rfc3588bis-13 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-11 == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-08 ** Obsolete normative reference: RFC 4006 (ref. '8') (Obsoleted by RFC 8506) ** Obsolete normative reference: RFC 3588 (ref. '9') (Obsoleted by RFC 6733) == Outdated reference: A later version (-17) exists of draft-ietf-dime-mip6-split-13 == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-06 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintanence and V. Fajardo, Ed. 3 Extensions (DIME) Toshiba America Research Inc. 4 Internet-Draft T. Asveren 5 Intended status: Informational Sonus Network 6 Expires: May 28, 2009 H. Tschofenig 7 Nokia Siemens Networks 8 G. McGregor 9 Alcatel-Lucent 10 J. Loughney 11 Nokia Research Center 12 November 24, 2008 14 Diameter Applications Design Guidelines 15 draft-ietf-dime-app-design-guide-08.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 May 28, 2009. 42 Abstract 44 The Diameter Base protocol provides updated rules on how to extend 45 Diameter by modifying and/or deriving from existing applications or 46 creating entirely new applications. This is a companion document to 47 the Diameter Base protocol that further explains and clarifies these 48 rules. It is meant as a guidelines document and therefore it does 49 not add, remove or change existing rules. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Adding a new command . . . . . . . . . . . . . . . . . . . . . 4 57 5. Deleting a Command . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Reusing Existing Commands . . . . . . . . . . . . . . . . . . 5 59 6.1. Adding AVPs to a Command . . . . . . . . . . . . . . . . . 6 60 6.2. Deleting AVPs from a Command . . . . . . . . . . . . . . . 7 61 7. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . . . 8 62 8. Rules for new Applications . . . . . . . . . . . . . . . . . . 8 63 8.1. Use of Application-Id in a Message . . . . . . . . . . . . 8 64 8.2. Application Specific Session State Machine . . . . . . . . 9 65 9. End-to-End Applications Capabilities Exchange . . . . . . . . 9 66 10. Diameter Accounting Support . . . . . . . . . . . . . . . . . 10 67 11. Generic Diameter Extensions . . . . . . . . . . . . . . . . . 11 68 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 16.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 16.2. Informative References . . . . . . . . . . . . . . . . . . 14 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 76 Intellectual Property and Copyright Statements . . . . . . . . . . 17 78 1. Introduction 80 The Diameter Base protocol document defines rules on how one would 81 extend Diameter (see Section 1.2 of [1]). In the context of this 82 document, extending Diameter means one of the following: 84 1. A new functionality is being added to an existing Diameter 85 application without defining a new application. 87 2. A new Diameter application is being defined by extending an 88 existing application. 90 3. A completely new application is being defined that has nothing in 91 common with existing applications. 93 4. A new generic functionality is being defined that can be reused 94 across different applications. 96 All of these choices are design decisions that can done by any 97 combination of reusing existing or defining new commands, AVPs or AVP 98 values. Protocol designers do, however, not have total freedom when 99 making their design. A number of rules defined in [1] place 100 constraints on when an extension demands a new Diameter Application 101 to be defined or a new Command Code to be registered. The objective 102 of this document is the following: 104 o Clarify updated Diameter extensibility rules in the Diameter Base 105 Protocol. 107 o Clarify usage of certain Diameter functionalitiessi which are not 108 explicitly described in the Diameter Base specification. 110 o Discuss design choices and provide guidelines when defining 111 applications. 113 o Present tradeoffs of design choices. 115 2. Terminology 117 This document reuses the terminology used in [1]. 119 3. Overview 121 As it is currently interpreted and practiced, the Diameter Base 122 protocol is a two-layer protocol. The lower layer is mainly 123 responsible for managing connections between neighboring peers and 124 for message routing. The upper layer is where the Diameter 125 applications reside. This model is in line with a Diameter node 126 having an application layer and a peer-to-peer delivery layer. The 127 Diameter Base protocol document completely defines the architecture 128 and behavior of the message delivery layer and then provides the 129 framework for designing Diameter applications on the application 130 layer. This framework includes definitions of application sessions 131 and accounting support (see Section 8 and 9 of [1]). The remainder 132 of this document also treats a Diameter node as a single instance of 133 a Diameter message delivery layer and one or more Diameter 134 applications using it. 136 Extending Diameter can mean the reuse of commands, AVPs and AVP 137 values in any combination for the purpose of inheriting the features 138 of an existing Diameter application. This section discusses the 139 rules on how such reuse can be done. 141 When reusing existing applications, the requirements of the new 142 applications are typically not completely unique and hence a lot can 143 be re-used from existing specifications. Therefore, there is a 144 greater likelihood of ambiguity on how much of the existing 145 application can be reused and what would be the implications for both 146 the new and existing application. To broadly categorize, the rules 147 for reusing existing applications can fall into two categories, as 148 listed below. 150 Minor Extension: This, for example, is the case when optional AVPs 151 are being defined. In general, this includes everything that is 152 not covered by the next category. The standardization effort will 153 be fairly small. 155 Major Extension: Such an extension requires the definition of a new 156 Diameter application. The rules outlined in Section 1.2 of [1] 157 indicate when an extension requires a a new Command Code to be 158 registered and when new Diameter applications have to be defined. 159 Typically, these types of extensions require a longer and more 160 careful effort depending on the degree of re-use. Therefore, the 161 amount of time and effort to complete the specification should 162 also be considered by the designer. 164 The subsequent sections provide discussions about the specific 165 Diameter Base protocol rules. 167 4. Adding a new command 169 Adding a new command is considered a major extension and requires a 170 new Diameter application to be defined. Adding a new command to an 171 application means either defining a completely new command or 172 importing an existing command from another application whereby the 173 new application inherits some or all of the functionality of the 174 application where the command came from. In the former case, the 175 decision to create an new application is straightforward since this 176 is typically a result of adding a new functionality that does not 177 exist yet. For the latter, the decision will depend on whether 178 importing the command in a new application is more suitable than 179 simply using the existing application as it is in conjunction with 180 any other application. Therefore, a case by case study of each 181 application requirement should be applied. 183 In general, it is difficult to come to a hard guideline, and so a 184 case by case study of each application requirement should be applied. 185 Before adding or importing a command, application designers should 186 consider the following: 188 o Can the new functionality be fulfilled by creating a new 189 application independent from the existing applications? In this 190 case, both old and new application can work independent of, but 191 cooperating with each other. 193 o Can the existing application be reused without major extensions 194 that requires the definition of a new application, e.g. new 195 funtionality introduced by the creation of new optional AVPs. 197 o Care should be taken to avoid a liberal method of importing 198 existing commands that results in a monolithic and hard to manage 199 application which supports many different functionalities. 201 5. Deleting a Command 203 Although this process is not typical, removing a command to an 204 application requires a new Diameter application to be defined. It is 205 unusual to delete an existing command from an application for the 206 sake of deleting it or the functionality it represents. This 207 normally indicates of a flawed design. An exception might be if the 208 intent of the deletion is to create a newer version of the same 209 application which is somehow simpler than the previous version. 211 6. Reusing Existing Commands 213 This section discusses rules in adding and/or deleting AVPs from an 214 existing command of an existing application. The cases described in 215 this section may not necessarily result in the creation of new 216 applications. 218 6.1. Adding AVPs to a Command 220 Based on the rules in [1], AVPs that are added to an existing command 221 can be categorized into: 223 o Mandatory to understand AVPs. As defined in [1], these are AVPs 224 with the M-bit flag set, which means that a Diameter node 225 receiving are required to understand not only their values but 226 their semantics. Failure to do so will cause an message handling 227 error. This is regardless of whether these AVPs are required or 228 optional as specified by the commands ABNF. 230 o Optional AVPs. [TBD] 232 The rules are strict in the case where the AVPs to be added are 233 mandatory. A mandatory AVP cannot be added to or deleted from an 234 existing command with defining a new Diameter application. [1] states 235 that doing so would require the definition of a new application. 236 This falls into the "Major Extensions" category. Despite the clarity 237 of the rule, ambiguity still arises when trying to decide whether a 238 new AVP being added should be mandatory to begin with. The follow 239 are a few common questions that application designers should 240 contemplate when trying to decide: 242 o Is it required for the receiving side to be able to process and 243 understand the AVP and its content (rather than just writing it's 244 content into to a file)? 246 o Do the AVPs change the state machine of the application ? 248 o Would the presence of the new AVPs (or the newly specified value 249 contained in an existing AVP) lead to a different number of 250 roundtrips, effectively changing the state machine of the 251 application? 253 o Would the AVP be used to differentiate between old and new 254 versions of the same application whereby the two versions are not 255 backward compatible? 257 o Will it have duality in meaning, i.e., be used to carry 258 application related information as well as be used to indicate 259 that the message is for a new application? 261 When one of the above questions can be answered with 'yes' then the 262 M-bit has to be set. If application designers are contemplating on 263 the use of optional AVPs instead, then the following are some of the 264 pitfalls that should be avoided: 266 o Use of optional AVPs with intersecting meaning. One AVP has 267 partially the same usage and meaning as another AVP. The presence 268 of both can lead to confusion. 270 o An optional AVPs with dual purpose, i.e. to carry applications 271 data as well as to indicate support for one or more features. 272 This has a tendency to introduce interpretation issues. 274 o Adding one or more optional AVPs and indicating (usually within 275 descriptive text for the command) that at least one of them has to 276 be present in the command. This essentially circumventing the 277 ABNF and is equivalent to adding a mandatory AVPs to the command. 279 These practices generally result in interoperability issues and 280 should be avoided as much as possible. 282 6.2. Deleting AVPs from a Command 284 When deleting an AVP from a Command the following cases need to be 285 differentiated: 287 o An AVP that is indicated as {} in the ABNF in the Command (with or 288 without the M-bit set). In this case the new Command Code and 289 subsequently a new Diameter application has to be specified. 291 o An AVP that is indicated as [] in the ABNF in the Command (with 292 the M-bit set). No new Command Code has to be specified but the 293 definition of a new Diameter application is required. 295 o An AVP that is indicated as [] in the ABNF in the Command (without 296 the M-bit set). In this case the AVP can be deleted without 297 consequences. 299 If possible application designers should attempt the reuse the 300 Command ABNF without modification and simply ignore (but not delete) 301 any optional AVP that will not be used. This is to maintain 302 compatibility with existing applications that will not know about the 303 new functionality as well as maintain the integrity of existing 304 dictionaries. 306 7. Reusing Existing AVPs 308 This section discusses rules in adding, deleting or modifying the 309 specified values of an AVP. 311 When reusing AVPs in a new application, the AVP flag setting, such as 312 the mandatory flag ('M'-bit), has to be re-evaluated for a new 313 Diameter application and, if necessary, even for every Command within 314 the application. In general, for AVPs defined outside of the base 315 protocol, its mandatory characteristics are tied to its role within 316 an application and Command. 318 8. Rules for new Applications 320 The general theme of Diameter extensibility is to reuse commands, 321 AVPs and AVP values as much as possible. However, some of the 322 extensibility rules described in the previous section also apply to 323 scenarios where a designer is trying to define a completely new 324 Diameter application. 326 This section discusses the case where new applications have 327 requirements that cannot be filled by existing applications and would 328 require definition of completely new commands, AVPs and/or AVP 329 values. Typically, there is little ambiguity about the decision to 330 create these types of applications. Some examples are the interfaces 331 defined for the IP Multimedia Subsystem of 3GPP, i.e. Cx/Dx ([2] and 332 [3]), Sh ([4] and [5]) etc. 334 Application designers should also follow the theme of Diameter 335 extensibility which in this case means to import existing AVPs and 336 AVP values for any newly defined commands. In certain cases where 337 accounting will be used, the models described in Section 10 should 338 also be considered. Though some decisions may be clear, designers 339 should also consider certain aspects of defining a new application. 340 Some of these aspects are described in following sections. 342 8.1. Use of Application-Id in a Message 344 When designing new applications, designers should specify that the 345 application ID carried in all session level messages must be the 346 application ID of the application using those messages. This 347 includes the session level messages defined in base protocol, i.e., 348 RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled 349 accounting model, see Section 10. Existing specifications may not 350 adhere to this rule for historical or other reasons. However, this 351 scheme should be followed to avoid possible routing problems for 352 these messages. 354 In general, when a new application has been allocated with a new 355 application id and it also reuses existing commands with or without 356 modifications (Sec 4.1), it must use the newly allocated application 357 id in the header and in all relevant application id AVPs (Auth- 358 Application-Id or Acct-Application-Id) present in the commands 359 message body. 361 Additionally, application designs using 362 Vendor-Specific-Application-Id AVP should not use the Vendor-Id AVP 363 to further dissect or differentiate the vendor-specification 364 application id. Diameter routing is not based on the Vendor-Id. As 365 such, the Vendor-ID should not be used as an additional input for 366 routing or delivery of messages. In general, the Vendor-Id AVP is an 367 informational AVP only and kept for backward compatibility reasons. 369 8.2. Application Specific Session State Machine 371 Section 8 of [1] provides session state machines for authentication, 372 authorization and accounting (AAA) services. When a new application 373 is being defined that cannot clearly be categorized into any of these 374 services it is recommended that the application itself define its own 375 session state machine. The existing session state machines defined 376 by [1] is not intended for general use beyond AAA services, therefore 377 any behavior not covered by that category would not fit well. 378 Support for server initiated request is a clear example where an 379 application specific session state machine would be needed, for 380 example, the Rw interface for ITU-T push model. 382 9. End-to-End Applications Capabilities Exchange 384 It is also possible that applications can use optional AVPs to 385 exchange application specific capabilities and features. These AVPs 386 are exchanged on an end-to-end basis. Examples of this can be found 387 in [6] and [7]. 389 The end-to-end capabilities AVPs can aid in the following cases: 391 o Formalizing the way new functionality is added to existing 392 applications by announcing support for it. 394 o Applications that do not understand these AVP can discard it upon 395 receipt. In such case, senders of the AVP can also safely assume 396 the receiving end-point does not support any functionality carried 397 by the AVP if it is not present in subsequent responses. 399 o Useful in cases where deployment choices are offered and the 400 generic design can be made available for a number of applications. 402 Note that this list is not meant to be comprehensive. 404 10. Diameter Accounting Support 406 Accounting can be treated as an auxiliary application which is used 407 in support of other applications. In most cases, accounting support 408 is required when defining new applications. This document provides 409 two(2) possible models for using accounting: 411 Split Accounting Model 413 In this model, the accounting messages will use the Diameter base 414 accounting application ID (value of 3). The design implication 415 for this is that the accounting is treated as an independent 416 application, especially during Diameter routing. This means that 417 accounting commands emanating from an application may be routed 418 separately from the rest of the other application messages. This 419 may also imply that the messages generally end up in a central 420 accounting server. A split accounting model is a good design 421 choice when: 423 * The application itself will not define its own unique 424 accounting commands. 426 * The overall system architecture permits the use of centralized 427 accounting for one or more Diameter applications. 429 Centralizing accounting may have advantages but there are also 430 drawbacks. The model assumes that the accounting server can 431 somehow differentiate received accounting messages. Since the 432 received accounting messages can be for any application and/or 433 service, the accounting server has to be have a method to uniquely 434 match accounting messages with applications and/or services being 435 accounted for. This may mean defining new AVPs, checking the 436 presence, absence or contents of existing AVPs or checking the 437 contents of the accounting records itself. But in general, there 438 is no clean and generic scheme for sorting these messages. 439 Therefore, the use of this model is recommended only when all 440 received accounting messages can be clearly identified and sorted. 441 For most cases, the use of Coupled Accounting Model is 442 recommended. 444 Coupled Accounting Model 446 In this model, the accounting messages will use the application ID 447 of the application using the accounting service. The design 448 implication for this is that the accounting messages are tightly 449 coupled with the application itself; meaning that accounting 450 messages will be routed like any other application messages. It 451 would then be the responsibility of the application server 452 (application entity receiving the ACR message) to send the 453 accounting records carried by the accounting messages to the 454 proper accounting server. The application server is also 455 responsible for formulating a proper response (ACA). A coupled 456 accounting model is a good design choice when: 458 * The system architecture or deployment will not provide an 459 accounting server that supports Diameter. 461 * The system architecture or deployment requires that the 462 accounting service for the specific application should be 463 handled by the application itself. 465 * The application server is provisioned to use a different 466 protocol to access the accounting server; e.g., via LDAP, SOAP 467 etc. This includes attempting to support older accounting 468 systems that are not Diameter aware. 470 In all cases above, there will generally be no direct Diameter 471 access to the accounting server. 473 These models provide a basis for using accounting messages. 474 Application designers may obviously deviate from these models 475 provided that the factors being addressed here have also been taken 476 into account. Though it is not recommended, examples of other 477 methods might be defining a new set of commands to carry application 478 specific accounting records. 480 11. Generic Diameter Extensions 482 Generic Diameter extensions are AVPs, commands or applications that 483 are designed to support other Diameter applications. They are 484 auxiliary applications meant to improve or enhance the Diameter 485 protocol itself or Diameter applications/functionality. Some 486 examples include the extensions to support auditing and redundancy 487 (see [12]), improvements in duplicate detection scheme (see [13]), 488 and piggybacking of QoS attributes (see [7]). 490 Since generic extensions can cover many aspects of Diameter and 491 Diameter applications, it is not possible to enumerate all the 492 probable scenarios in this document. However, some of the most 493 common considerations are as follows: 495 o Backward compatibility: Dealing with existing applications that do 496 not understand the new extension. Designers also have to make 497 sure that new extensions do not break expected message delivery 498 layer behavior. 500 o Forward compatibility: Making sure that the design will not 501 introduce undue restrictions for future applications. Future 502 applications attempting to support this feature should not have to 503 go through great lengths to implement any new extensions. 505 o Tradeoffs in signaling: Designers may have to choose between the 506 use of optional AVPs piggybacked onto existing commands versus 507 defining new commands and applications. Optional AVPs are simpler 508 to implement and may not need changes to existing applications; 509 However, the drawback is that the timing of sending extension data 510 will be tied to when the application would be sending a message. 511 This has consequences if the application and the extensions have 512 different timing requirements. The use of commands and 513 applications solves this issue but the tradeoff is the additional 514 complexity of defining and deploying a new application. It is 515 left up to the designer to find a good balance among these 516 tradeoffs based on the requirements of the extension. 518 In practice, it is often the case that the generic extensions use 519 optional AVPs because it's simple and not intrusive to the 520 application that would carry it. Peers that do not support the 521 generic extensions need not understand nor recognize these optional 522 AVPs. However, it is recommended that the authors of the extension 523 specify the context or usage of the optional AVPs. As an example, in 524 the case that the AVP can be used only by a specific set of 525 applications then the specification must enumerate these applications 526 and the scenarios when the optional AVPs will be used. In the case 527 where the optional AVPs can be carried by any application, it is 528 should be sufficient to specify such a use case and perhaps provide 529 specific examples of applications using them. 531 In most cases, these optional AVPs piggybacked by applications would 532 be defined as a Grouped AVP and it would encapsulate all the 533 functionality of the generic extension. In practice, it is not 534 uncommon that the Grouped AVP will encapsulate an existing AVP that 535 has previously been defined as mandatory ('M'-bit set) e.g., 3GPP IMS 536 Cx / Dx interfaces ([2] and [3]). 538 12. IANA Considerations 540 This document does not require actions by IANA. 542 13. Security Considerations 544 This document does provides guidelines and considerations for 545 extending Diameter and Diameter applications. It does not define nor 546 address security related protocols or schemes. 548 14. Contributors 550 The content of this document was influenced by a design team created 551 to revisit the Diameter extensibility rules. The team consisting of 552 the members listed below was formed in February 2008 and finished its 553 work in June 2008. 555 o Avi Lior 556 o Glen Zorn 557 o Jari Arkko 558 o Lionel Morand 559 o Mark Jones 560 o Victor Fajardo 561 o Tolga Asveren 562 o Jouni Korhonen 563 o Glenn McGregor 564 o Hannes Tschofenig 565 o Dave Frascone 567 15. Acknowledgments 569 We greatly appreciate the insight provided by Diameter implementers 570 who have highlighted the issues and concerns being addressed by this 571 document. 573 16. References 575 16.1. Normative References 577 [1] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter 578 Base Protocol", draft-ietf-dime-rfc3588bis-13 (work in 579 progress), November 2008. 581 [2] 3GPP, "IMS Cx and Dx interfaces : signalling flows and message 582 contents", 3GPP TS 29.228 Version 7.0.0 2006. 584 [3] 3GPP, "IMS Cx and Dx interfaces based on the Diameter protocol; 585 Protocol details", 3GPP TS 29.229 Version 7.0.0 2006. 587 [4] 3GPP, "IMS Sh interface : signalling flows and message 588 content", 3GPP TS 29.328 Version 6.8.0 2005. 590 [5] 3GPP, "IMS Sh interface based on the Diameter protocol; 591 Protocol details", 3GPP TS 29.329 Version 6.6.0 2005. 593 [6] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and 594 K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access 595 Server to Diameter Server Interaction", 596 draft-ietf-dime-mip6-integrated-11 (work in progress), 597 November 2008. 599 [7] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and 600 A. Lior, "Quality of Service Attributes for Diameter", 601 draft-ietf-dime-qos-attributes-08 (work in progress), 602 October 2008. 604 [8] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 605 Loughney, "Diameter Credit-Control Application", RFC 4006, 606 August 2005. 608 [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 609 "Diameter Base Protocol", RFC 3588, September 2003. 611 [10] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and 612 M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to 613 Diameter Server Interaction", draft-ietf-dime-mip6-split-13 614 (work in progress), October 2008. 616 [11] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and 617 G. Zorn, "Diameter Quality of Service Application", 618 draft-ietf-dime-diameter-qos-06 (work in progress), July 2008. 620 16.2. Informative References 622 [12] Calhoun, P., "Diameter Resource Management Extensions", 623 draft-calhoun-diameter-res-mgmt-08.txt (work in progress), 624 March 2001. 626 [13] Asveren, T., "Diameter Duplicate Detection Cons.", 627 draft-asveren-dime-dupcons-00 (work in progress), August 2006. 629 Authors' Addresses 631 Victor Fajardo (editor) 632 Toshiba America Research Inc. 633 One Telcordia Drive, #1S222 634 Piscataway, NJ 08854 635 USA 637 Email: vfajardo@tari.toshiba.com 639 Tolga Asveren 640 Sonus Network 641 4400 Route 9 South 642 Freehold, NJ 07728 643 USA 645 Email: tasveren@sonusnet.com 647 Hannes Tschofenig 648 Nokia Siemens Networks 649 Linnoitustie 6 650 Espoo 02600 651 Finland 653 Phone: +358 (50) 4871445 654 Email: Hannes.Tschofenig@gmx.net 655 URI: http://www.tschofenig.priv.at 657 Glenn McGregor 658 Alcatel-Lucent 659 3461 Robin Ln Ste 1 660 Cameron Park, CA 95682 661 USA 663 Email: glenn@aaa.lucent.com 664 John Loughney 665 Nokia Research Center 666 955 Page Mill Road 667 Palo Alto, CA 94304 668 US 670 Phone: 1-650-283-8068 671 Email: john.loughney@nokia.com 673 Full Copyright Statement 675 Copyright (C) The IETF Trust (2008). 677 This document is subject to the rights, licenses and restrictions 678 contained in BCP 78, and except as set forth therein, the authors 679 retain all their rights. 681 This document and the information contained herein are provided on an 682 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 683 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 684 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 685 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 686 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 687 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 689 Intellectual Property 691 The IETF takes no position regarding the validity or scope of any 692 Intellectual Property Rights or other rights that might be claimed to 693 pertain to the implementation or use of the technology described in 694 this document or the extent to which any license under such rights 695 might or might not be available; nor does it represent that it has 696 made any independent effort to identify any such rights. Information 697 on the procedures with respect to rights in RFC documents can be 698 found in BCP 78 and BCP 79. 700 Copies of IPR disclosures made to the IETF Secretariat and any 701 assurances of licenses to be made available, or the result of an 702 attempt made to obtain a general license or permission for the use of 703 such proprietary rights by implementers or users of this 704 specification can be obtained from the IETF on-line IPR repository at 705 http://www.ietf.org/ipr. 707 The IETF invites any interested party to bring to its attention any 708 copyrights, patents or patent applications, or other proprietary 709 rights that may cover technology that may be required to implement 710 this standard. Please address the information to the IETF at 711 ietf-ipr@ietf.org.