idnits 2.17.1 draft-ietf-dime-app-design-guide-01.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 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 693. 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 (June 6, 2007) is 6169 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3588 (ref. '1') (Obsoleted by RFC 6733) == Outdated reference: A later version (-17) exists of draft-ietf-dime-mip6-split-02 == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-00 ** Obsolete normative reference: RFC 4006 (ref. '8') (Obsoleted by RFC 8506) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: December 8, 2007 H. Tschofenig 7 Nokia Siemens Networks 8 G. McGregor 9 Alcatel-Lucent 10 J. Loughney 11 Nokia Research Center 12 June 6, 2007 14 Diameter Applications Design Guidelines 15 draft-ietf-dime-app-design-guide-01.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 December 8, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 The Diameter Base protocol provides rules on how to extend Diameter 49 and to create new Diameter applications. This is a companion 50 document to clarify these rules. This document does not intended to 51 add, remove or change these rules, rather it helps protocol designers 52 to extend Diameter. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Diameter Application Model . . . . . . . . . . . . . . . . . . 3 59 4. Rules on Diameter Extensibility . . . . . . . . . . . . . . . 4 60 4.1. Rules on Extending Existing Applications . . . . . . . . . 5 61 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 7 62 5.1. Diameter Accounting Support . . . . . . . . . . . . . . . 7 63 5.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 8 64 5.3. Updating an existing Application . . . . . . . . . . . . . 9 65 5.4. Use of optional AVPs . . . . . . . . . . . . . . . . . . . 10 66 5.5. Deleting AVPs from a Command ABNF . . . . . . . . . . . . 10 67 5.6. Justifying the Allocation of Application-Id . . . . . . . 11 68 5.7. Use of Application-Id in a Message . . . . . . . . . . . . 11 69 5.8. Application Specific Session Statemachine . . . . . . . . 11 70 5.9. System Architecture and Deployment . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 78 Intellectual Property and Copyright Statements . . . . . . . . . . 16 80 1. Introduction 82 The Diameter Base protocol document defines rules on how one would 83 extend Diameter (see Section 1.2 of [1]). In the context of this 84 document, extending Diameter means that a new Diameter application is 85 being defined which may or may not be based on an existing Diameter 86 application. A decision to define a new application would mean 87 allocation of a new application ID. 89 By themselves, the rules defined in the Diameter Base protocol are 90 not necessarily comprehensive enough that one can easily derive good 91 design decisions from them. The effect of this can be seen in 92 various attempts to extend Diameter where protocol designers have no 93 clear answer on whether to even define a new application or not. At 94 worst, some existing Diameter applications that had purposely been 95 derived from another existing application resulted in some in- 96 appropriate design decision in which both applications are no longer 97 interoperable in certain conditions. 99 The intent of this document is to influence ongoing and future 100 Diameter application design by providing the following content: 102 o Clarify existing Diameter extensibility rules present in the 103 Diameter Base Protocol. 105 o Clarify usage of certain Diameter functionality which are not 106 explicitly described in the Diameter Base specification. 108 o Discuss design choices when defining new applications. 110 o Present tradeoffs of design choices. 112 Note that it is not always possible to offer a complete and concise 113 answer to certain design choices. There is, however, the belief that 114 at a minimum, this document can be used as a guide to Diameter 115 extensibility. 117 2. Terminology 119 This document reuses the terminology used in [1]. 121 3. Diameter Application Model 123 As it is currently interpreted and practiced, the Diameter Base 124 protocol is a two-layer protocol. The lower layer is mainly 125 responsible for managing connections between neighboring peers and 126 for message routing. The upper layer is where the Diameter 127 applications reside. This model is inline with a Diameter node 128 having an application layer and a peer-to-peer delivery layer. The 129 Diameter Base protocol document completely defines the architecture 130 and behavior of the message delivery layer and then provides the 131 framework for designing Diameter applications on the application 132 layer. This framework includes definitions of application sessions 133 and accounting support (see Section 8 and 9 of [1]). The remainder 134 of this document also treats a Diameter node as a single instance of 135 a Diameter message delivery layer and one or more Diameter 136 applications using it. 138 4. Rules on Diameter Extensibility 140 The general theme of Diameter extensibility is to reuse AVPs, AVP 141 values, commands and applications as much as possible. However, 142 there are also rules for extending Diameter as specified in Section 143 1.2 of [1]. As is, the rules apply to the scenario where one is 144 trying to define a new Diameter application. Defining a new Diameter 145 application can be done by: 147 Defining a completely new application 149 This case applies to applications which have requirements that 150 cannot be filled by existing applications and would require 151 definition of new command(s), AVPs and AVP values. Typically, 152 there is little ambiguity about the decision to create these types 153 of applications. Some examples are the interfaces defined for the 154 IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([2] and [3]), Sh 155 ([4] and [5]) etc . Though some decisions may be clear, designers 156 should also consider certain aspects of the application itself. 157 Some of these are described in Section 5. Applications design 158 should also follow the theme of Diameter extensibility which 159 advocates reuse of AVPs and AVP values as much as possible even in 160 newly defined commands. In certain cases where accounting will be 161 used, the models described in Section 5.1 should be considered. 163 Extending an existing application 165 In this case, the requirements of the new applications are not 166 completely unique and there are existing application's that can be 167 reused to solve some or all of the application requirements. 168 Thus, there is a greater likelihood of ambiguity on how much of 169 the existing application can be reused, to what extent and what 170 the implications for both the new and existing application. 171 Section 4.1 discusses some of the issues in this case. 173 4.1. Rules on Extending Existing Applications 175 The Diameter base protocol provides a clear set of rules on when one 176 should define a new Diameter application. In the context of this 177 document, the rules are: 179 Adding an AVP to a command ABNF of an existing application 181 The rules are strict in the case where the AVP(s) to be added is 182 mandatory. As defined in [1], a mandatory AVP is an AVP that has 183 its M-bit flag set which requires a receiver to understand, 184 correctly interpret and process the AVP when it is present in a 185 message. This rule is independent of whether the AVP is defined 186 as required or optional to exist in a message. As long as the AVP 187 will added to a messages' ABNF then this rule will apply. 189 The mandatory AVP rules applies to AVP(s) that either already 190 exist in the same or in another application or the AVP(s) are yet 191 to be defined. The ambiguity arises when trying to decide whether 192 the AVP(s) should be mandatory or not. There are several 193 questions that application designers should contemplate when 194 trying to decide: 196 * Does the AVP(s) change the state machine of the application ? 198 * Would the presence of the AVP(s) cause additional message 199 round-trips; effectively changing the state machine of the 200 application ? 202 * Will the AVP be used to fulfill new required functionality ? 204 * Would the AVP be used to differentiate between old and new 205 versions of the same application ? 207 * Will it have duality in meaning; i.e., be used to carry 208 application related information as well as be used to indicate 209 that the message is for a new application ? 211 These questions are not comprehensive in any way but in all cases 212 the semantics of the application must change to justify the use of 213 mandatory AVPs. 215 However, care should also be taken when opting for optional AVPs 216 instead of mandatory AVPs simply to avoid allocating new 217 applications. Optional AVPs that fall into any of the categorical 218 questions above would have consequences. See Section 5.4 for 219 details. 221 Add a new AVP value to an to an existing AVP 223 In this case, the rule applies to existing mandatory AVPs already 224 present in a command ABNF where the semantics of the AVP changes. 225 This means that the meaning or usage of the AVP has changed and 226 significantly affects the behavior of the application. Although 227 this case may be less common or seem more subtle, the exact same 228 considerations given in the first scenario above apply here as 229 well. 231 Add a command to an existing application 233 In this case, the rule applies to defining a new command for an 234 existing application or importing an existing command from another 235 application so as to inherit some or all of the functionality of 236 that application. In the first case, the decision is straight 237 forward since this is typically a result of adding new 238 functionality that does not yet exist. The latter case would 239 result in a new application but it has a more subtle issue such as 240 deciding whether importing of commands and functionality is really 241 better than simply using the existing application as it is in 242 conjunction with any new application. 244 A typical example would be the Diameter MIPv6 split scenario (see 245 [6]) in which several application models would have been possible 246 during the design phase; one model would reuse existing Diameter 247 EAP application combined with a new Diameter MIPv6 application to 248 form a complete authentication and authorization scheme and 249 another would be to reuse Diameter EAP like commands within the 250 new Diameter MIPv6 application to accomplish the same result. In 251 this case, the latter model was chosen which would permit the 252 reuse of commands and/or AVPs from one application to another. 253 Other applications such as Diameter QoS (see [7]) would likely 254 face similar decisions. 256 In general, it is difficult to come to a hard and fast guideline 257 for this scenario so a case by case study of each application 258 requirement should be applied. Before importing a command, 259 application designers should consider whether: 261 * The existing application can be reused as is without 262 fundamental changes; i.e. an optional AVP is sufficient to 263 indicate support for new optional functionality if any. There 264 are pitfalls to this as well. See Section 5.4 266 * Reuse of existing applications would result in a distributed 267 environment which may not be conducive to certain requirements 268 of the applications; i.e. security and or deployment 269 difficulties - because of Diameter routing, messages for 270 different applications providing service to the same user may 271 end up in different servers would then need to be co-related. 272 This could mean extra signaling between application servers. A 273 typical example would be the initial proposal for Diameter 274 MIPv6 split scenario (see [6]) where authorization and 275 authentication is separated. 277 5. Design Considerations 279 The following are some of the design considerations that apply to a 280 Diameter application. 282 5.1. Diameter Accounting Support 284 Accounting can be treated as an auxiliary application which is used 285 in support of other applications. In most cases, accounting support 286 is required when defining new applications. However, the lack of 287 clarity in the base protocol document has prevented easy use the base 288 accounting messages (ACR/ACA). This document provides two(2) 289 possible models for using accounting: 291 Split Accounting Model 293 In this model, the accounting messages will use the Diameter base 294 accounting application ID (value of 3). The design implication 295 for this is that the accounting is treated as an independent 296 application, especially during routing. This means that 297 accounting commands emanating from an application may be routed 298 separately from the rest of the other application messages. This 299 also implies that the messages generally end up in a central 300 accounting server. A split accounting model is a good design 301 choice when: 303 * The application itself will not define its own unique 304 accounting commands. 306 * The overall system architecture permits the use of centralized 307 accounting for one or more Diameter applications. 309 From a Diameter architecture perspective, this model should be the 310 typical design choice. Note that when using this model, the 311 accounting server must use the Acct-Application-Id AVP to 312 determine which application is being accounted for. Therefore, 313 the application designer should specify the proper values used in 314 Acct-Application-Id AVP when sending ACR messages. 316 Coupled Accounting Model 318 In this model, the accounting messages will use the application ID 319 of the application using the accounting service. The design 320 implication for this is that the accounting messages is tightly 321 coupled with the application itself; meaning that accounting 322 messages will be routed like any other application messages. It 323 would then be the responsibility of the application server 324 (application entity receiving the ACR message) to send the 325 accounting records carried by the accounting messages to the 326 proper accounting server. The application server is also 327 responsible for formulating a proper response (ACA). A coupled 328 accounting model is a good design choice when: 330 * The system architecture or deployment will not provide an 331 accounting server that supports Diameter. 333 * The system architecture or deployment requires that the 334 accounting service for the specific application should be 335 handled by the application itself. 337 * The application server is provisioned to use a different 338 protocol to access the accounting server; i.e., via LDAP, XML 339 etc. This includes attempting to supporting older accounting 340 systems that are not Diameter aware. 342 In all cases above, there will generally be no direct Diameter 343 access to the accounting server. 345 These models provide a basis for using accounting messages. 346 Application designers may obviously deviate from these models 347 provided that the factors being addressed here have also been taken 348 into account. Though it is not recommended, examples of other 349 methods would be defining a new set of commands to carry application 350 specific accounting records. 352 Additionally, the application ID in the message header and 353 Accounting-Application-Id AVP are populated depending on the 354 accounting model used for a specific application, as described in 355 [1]. Therefore, application designers have to specify the accounting 356 model used to guarantee proper routing of accounting requests. 358 5.2. Generic Diameter Extensions 360 Generic Diameter extensions are AVPs, commands or applications that 361 are designed to support other Diameter applications. They are 362 auxiliary applications meant to improve or enhance the Diameter 363 protocol itself or Diameter applications/functionality. Some 364 examples include the extensions to support auditing and redundancy 365 (see [9]), improvements in duplicate detection scheme (see [10]). 367 Since generic extensions can cover many aspects of Diameter and 368 Diameter applications, it is not possible to enumerate all the 369 probable scenarios in this document. However, some of the most 370 common considerations are as follows: 372 o Backward compatibility: Dealing with existing applications that do 373 not understand the new extension. Designers also have to make 374 sure that new extensions do not break expected message delivery 375 layer behavior. 377 o Forward compatibility: Making sure that the design will not 378 introduce undue restrictions for future applications. Future 379 applications attempting to support this feature should not have to 380 go through great lengths to implement any new extensions. 382 o Tradeoffs in signaling: Designers may have to choose between the 383 use of optional AVPs piggybacked onto existing commands versus 384 defining new commands and applications. Optional AVPs are simpler 385 to implement and may not need changes to existing applications; 386 i.e., use of proxy agents. However, the drawback is that the 387 timing of sending extension data will be tied to when the 388 application would be sending a message. This has consequences if 389 the application and the extensions have different timing 390 requirements. The use of commands and applications solves this 391 issue but the tradeoff is the additional complexity of defining 392 and deploying a new application. It is left up to the designer to 393 find a good balance among these tradeoffs based on the 394 requirements of the extension. 396 5.3. Updating an existing Application 398 An application that is being upgraded must follow the same rules 399 mentioned Section 4. Even if the new version is fundamentally the 400 same application, allocation of a new application ID is possible if 401 it meets those criteria. 403 Optional AVPs can also be used to indicate version differences. If 404 this approach is chosen, it is recommended that the optional AVP is 405 used specifically to indicate version information only and nothing 406 else. Additionally, the use of too many optional AVPs to carry 407 application enhancements should be avoided since such approach has a 408 tendency to become unmanageable and introduce interoperability 409 issues. These pitfalls are discussed in Section 5.4 410 For the same reason, care should be taken in attempting to justify 411 allocation of new application ID for every change. The pitfalls of 412 this approach is discussed in Section 5.6. 414 5.4. Use of optional AVPs 416 Problems arise when there is a tendency by applications designers to 417 keep adding optional AVPs to an existing command so they can 418 circumvent the extension rules in Section 4. Some of the pitfalls 419 that application designers should avoid are: 421 o Use of optional AVPs with intersecting meaning; one AVP has 422 partially the same usage and/or meaning as another AVP. The 423 presence of both can lead to confusion. 425 o Optional AVPs with dual purpose; i.e.; to carry applications data 426 as well as to indicate support for one or more features. This has 427 a tendency to introduce interpretation issues. 429 o Use of optional AVPs with a minimum occurrence of one(1) in the 430 command ABNF. This is generally contradictory. Application 431 designers should not use this scheme to circumvent definition of 432 mandatory AVPs. 434 All of these practices generally result in interoperability problems 435 so they should be avoided as much as possible. 437 5.5. Deleting AVPs from a Command ABNF 439 Although this scenario is not as common, the deletion of AVPs from a 440 command ABNF is significant when trying to extend an existing 441 application. Deletion can be categorized between deletion of 442 mandatory and optional AVPs. 444 In the unlikely event that an application designer would require that 445 mandatory AVPs must be deleted then it constitutes a fundamental 446 change to an existing application. Though not specified in [1], 447 deletion of mandatory would most likely require the allocation of a 448 new application since it dictates changes in the behavior and 449 semantics of an application. 451 Additionally, it is highly recommended that a new command code be 452 defined that would represent the new behavior. Reusing the same 453 command code would lead to more confusion since the command will have 454 different semantics depending usage or context. This applies 455 especially to some of the base protocol commands (session related 456 commands defined in [1]) where they are being used by many different 457 applications. 459 The deletion of an optional AVP may not necessarily indicate 460 allocation of a new application. An optional AVP with a minimum 461 occurrence of at least one(1) in the command ABNF would mean that the 462 AVP is required and that if deleted, there would effectively be 463 changes to the behavior of the application as well. Such cases are 464 highly dubious to begin with since those AVPs already exhibits 465 properties of mandatory AVPs. It should therefore fall into the 466 category of deleting mandatory AVPs. 468 In other cases, it is recommended that application designers reuse 469 the command ABNF as is and safely ignore (but not delete) any 470 optional AVP that will not be used. This is to maintain 471 compatibility with existing applications that will not know about the 472 new functionality as well as maintain the integrity of existing 473 dictionaries. 475 5.6. Justifying the Allocation of Application-Id 477 Application designers should avoid justifying the allocation of 478 application IDs for every change that is made to an existing 479 application. Proliferation of application ID can lead to confusion 480 and an in-efficient use of the application ID namespaces. 481 Application designers should always use Section 4 as a basis for 482 justifying allocation of a new application ID. 484 5.7. Use of Application-Id in a Message 486 When designing new applications, designers should specify that the 487 application ID carried in all session level messages must be the 488 application ID of the application using those messages. This 489 includes the session level messages defined in base protocol, i.e., 490 RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled 491 accounting model, see Section 5.1. Existing specifications may not 492 adhere to this rule for historical or other reasons. However, this 493 scheme is followed to avoid possible routing problems for these 494 messages. 496 Additionally, application designers using the Vendor-Specific- 497 Application-Id AVP should note that the Vendor-Id AVP will not be 498 used in any way by the Diameter message delivery layer. Therefore 499 its meaning and usage should be segregated only within the 500 application. 502 5.8. Application Specific Session Statemachine 504 Section 8 of [1] provides session statemachines for authentication, 505 authorization and accounting (AAA) services. When a new application 506 is being defined that cannot clearly be categorized into any of these 507 services it is recommended that the application itself defines its 508 own session statemachine. The existing session statemachines defined 509 by [1] is not intended for general use beyond AAA services therefore 510 any new behavior would most likely not fit well. Support for server 511 initiated request is a clear example where an application specific 512 session statemachine would be needed; i.e. Rw interface for ITU-T 513 push model. 515 5.9. System Architecture and Deployment 517 The following are some of the architecture considerations that 518 applications designers should contemplate when defining new 519 applications: 521 o For general AAA applications, Diameter requires more message 522 exchanges for the same set of services compared to RADIUS. 523 Therefore, application designers should consider scalability 524 issues during the design process. 526 o Application design should be agnostic to any Diameter topology. 527 Application designers should not always assume a particular 528 Diameter topology; i.e., assume that there will always be 529 application proxies in the path or assume that only intra-domain 530 routing is applicable. 532 o Security Considerations. Application designers should take into 533 account that there is no end-to-end authentication built into 534 Diameter. 536 o Application design should consider some form of redundancy. 537 Session state information is the primary data necessary for 538 backup/recovering endpoints to continue processing for an 539 previously existing session. Carrying enough information in the 540 messages to reconstruct session state facilitates redundant 541 implementations and is highly recommended. 543 o Application design should segregate message delivery layer 544 processing from application level processing. An example is the 545 use of timers to detect lack of a response for a previously sent 546 requests. Although the Diameter base protocol defines a watchdog 547 timer Tw, its use on application level is discouraged since Tw is 548 a hop-by-hop timer and it would not be relevant for end-to-end 549 message delivery error detection. In such a case, it is 550 recommended that applications should define their own set of 551 timers for such purpose. 552 o Applications should specify AVPs which could be used to further 553 aid in duplication detection. In some cases, when extending an 554 application, existing AVPs can be reused to provide additional 555 duplication detection indicators; i.e., combination of Session-Id 556 and CC-Request-Number AVPs in the Diameter Credit Control 557 application [8]. In cases where the extensions needs to define 558 new AVPs, it is recommended that the new AVPs be used only for 559 this purpose. 561 6. IANA Considerations 563 This document does not require actions by IANA. 565 7. Security Considerations 567 This document does provides guidelines and considerations for 568 extending Diameter and Diameter applications. It does not define nor 569 address security related protocols or schemes. 571 8. Acknowledgments 573 We greatly appreciate the insight provided by Diameter implementers 574 who have highlighted the issues and concerns being addressed by this 575 document. 577 9. References 579 9.1. Normative References 581 [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 582 "Diameter Base Protocol", RFC 3588, September 2003. 584 [2] 3GPP, "IMS Cx and Dx interfaces : signalling flows and message 585 contents", 3GPP TS 29.228 Version 7.0.0 2006. 587 [3] 3GPP, "IMS Cx and Dx interfaces based on the Diameter protocol; 588 Protocol details", 3GPP TS 29.229 Version 7.0.0 2006. 590 [4] 3GPP, "IMS Sh interface : signalling flows and message 591 content", 3GPP TS 29.328 Version 6.8.0 2005. 593 [5] 3GPP, "IMS Sh interface based on the Diameter protocol; 594 Protocol details", 3GPP TS 29.329 Version 6.6.0 2005. 596 [6] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support", 597 draft-ietf-dime-mip6-split-02 (work in progress), May 2007. 599 [7] Zorn, G., "Diameter Quality of Service Application", 600 draft-ietf-dime-diameter-qos-00 (work in progress), 601 February 2007. 603 [8] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 604 Loughney, "Diameter Credit-Control Application", RFC 4006, 605 August 2005. 607 9.2. Informative References 609 [9] Calhoun, P., "Diameter Resource Management Extensions", 610 draft-calhoun-diameter-res-mgmt-08.txt (work in progress), 611 March 2001. 613 [10] Asveren, T., "Diameter Duplicate Detection Cons.", 614 draft-asveren-dime-dupcons-00 (work in progress), August 2006. 616 Authors' Addresses 618 Victor Fajardo (editor) 619 Toshiba America Research Inc. 620 One Telcordia Drive 621 Piscataway, NJ 08854 622 USA 624 Email: vfajardo@tari.toshiba.com 626 Tolga Asveren 627 Sonus Network 628 4400 Route 9 South 629 Freehold, NJ, 07728 630 USA 632 Email: tasveren@sonusnet.com 634 Hannes Tschofenig 635 Nokia Siemens Networks 636 Otto-Hahn-Ring 6 637 Munich, Bavaria 81739 638 Germany 640 Phone: +49 89 636 40390 641 Email: Hannes.Tschofenig@nsn.com 642 URI: http://www.tschofenig.com 643 Glenn McGregor 644 Alcatel-Lucent 645 USA 647 Email: glenn@aaa.lucent.com 649 John Loughney 650 Nokia Research Center 651 USA 653 Email: john.loughney@nokia.com 655 Full Copyright Statement 657 Copyright (C) The IETF Trust (2007). 659 This document is subject to the rights, licenses and restrictions 660 contained in BCP 78, and except as set forth therein, the authors 661 retain all their rights. 663 This document and the information contained herein are provided on an 664 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 665 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 666 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 667 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 668 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 669 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 671 Intellectual Property 673 The IETF takes no position regarding the validity or scope of any 674 Intellectual Property Rights or other rights that might be claimed to 675 pertain to the implementation or use of the technology described in 676 this document or the extent to which any license under such rights 677 might or might not be available; nor does it represent that it has 678 made any independent effort to identify any such rights. Information 679 on the procedures with respect to rights in RFC documents can be 680 found in BCP 78 and BCP 79. 682 Copies of IPR disclosures made to the IETF Secretariat and any 683 assurances of licenses to be made available, or the result of an 684 attempt made to obtain a general license or permission for the use of 685 such proprietary rights by implementers or users of this 686 specification can be obtained from the IETF on-line IPR repository at 687 http://www.ietf.org/ipr. 689 The IETF invites any interested party to bring to its attention any 690 copyrights, patents or patent applications, or other proprietary 691 rights that may cover technology that may be required to implement 692 this standard. Please address the information to the IETF at 693 ietf-ipr@ietf.org. 695 Acknowledgment 697 Funding for the RFC Editor function is provided by the IETF 698 Administrative Support Activity (IASA).