idnits 2.17.1 draft-ietf-dime-app-design-guide-06.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 962. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 986. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 23, 2008) is 5937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-dime-rfc3588bis-10 == Outdated reference: A later version (-17) exists of draft-ietf-dime-mip6-split-06 == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-02 ** Obsolete normative reference: RFC 4006 (ref. '4') (Obsoleted by RFC 8506) ** Obsolete normative reference: RFC 3588 (ref. '9') (Obsoleted by RFC 6733) == Outdated reference: A later version (-15) exists of draft-ietf-dime-qos-attributes-04 == Outdated reference: A later version (-12) exists of draft-ietf-dime-mip6-integrated-07 Summary: 3 errors (**), 0 flaws (~~), 6 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: July 26, 2008 H. Tschofenig 7 Nokia Siemens Networks 8 G. McGregor 9 Alcatel-Lucent 10 J. Loughney 11 Nokia Research Center 12 January 23, 2008 14 Diameter Applications Design Guidelines 15 draft-ietf-dime-app-design-guide-06.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 July 26, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 The Diameter Base protocol provides updated rules on how to extend 49 Diameter by modifying and/or deriving from existing applications or 50 creating entirely new applications. This is a companion document to 51 the Diameter Base protocol which further explains and/or clarify 52 these rules. It is meant as a guidelines document and therefore it 53 does not add, remove or change existing rules. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Brief Overview of the Diameter Application Model . . . . . . . 4 60 4. Rules on Extending Diameter . . . . . . . . . . . . . . . . . 4 61 4.1. Reusing Existing Applications . . . . . . . . . . . . . . 5 62 4.1.1. Adding a new command . . . . . . . . . . . . . . . . . 6 63 4.1.2. Deleting a command . . . . . . . . . . . . . . . . . . 7 64 4.2. Reusing Existing Commands . . . . . . . . . . . . . . . . 7 65 4.2.1. Adding AVPs to a command . . . . . . . . . . . . . . . 7 66 4.2.2. Deleting AVPs from a command . . . . . . . . . . . . . 9 67 4.3. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 10 68 5. Rules for new Applications . . . . . . . . . . . . . . . . . . 11 69 5.1. Rules in Allocating new Command Codes . . . . . . . . . . 11 70 5.2. Justifying the Allocation of Application-Id . . . . . . . 11 71 5.3. Use of Application-Id in a Message . . . . . . . . . . . . 12 72 5.4. Application Specific Session Statemachine . . . . . . . . 12 73 5.5. End-to-End Applications Capabilities Exchange . . . . . . 12 74 6. Other Design Considerations . . . . . . . . . . . . . . . . . 13 75 6.1. Diameter Accounting Support . . . . . . . . . . . . . . . 13 76 6.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 15 77 6.3. Updating an existing Application . . . . . . . . . . . . . 16 78 6.4. Use of Mandatory (M-bit) flags . . . . . . . . . . . . . . 17 79 6.5. System Architecture and Deployment . . . . . . . . . . . . 17 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 87 Intellectual Property and Copyright Statements . . . . . . . . . . 22 89 1. Introduction 91 The Diameter Base protocol document defines rules on how one would 92 extend Diameter (see Section 1.2 of [1]). In the context of this 93 document, extending Diameter means one of the following: 95 1. A new functionality is being added to an existing Diameter 96 application without defining a new application. 98 2. A new Diameter application is being defined by reusing an 99 existing application. 101 3. A completely new application is being defined that has no 102 dependencies to any existing applications. 104 4. A new generic functionality is being defined that can be reused 105 across different applications. 107 All of these choices are design decisions that can done by any 108 combination of reusing existing or defining new commands, AVPs or AVP 109 values. The objective of this document is the following: 111 o Clarify updated Diameter extensibility rules in the Diameter Base 112 Protocol. 114 o Clarify usage of certain Diameter functionality which are not 115 explicitly described in the Diameter Base specification. 117 o Discuss design choices and provide guidelines when defining 118 applications. 120 o Present tradeoffs of design choices. 122 These guidelines are necessary since the existing rules do not cover 123 the ambiguity that exists when some of the design choices overlap. A 124 typical example would be deciding between item one(1) and two(2) 125 above when an application designer requires a new application 126 functionality which has many things in common with an existing 127 application. Certain ambiguous aspects of such cases were not 128 foreseen in the existing extensibility rules; e.g., use of optional 129 AVPs to differentiate new functionality in the old application versus 130 defining a new application and importing the existing set of 131 commands. In this example, it was only based on collective 132 experiences of application designers that the decision to create a 133 new application (item two(2)) is now seen as the cleanest approach. 135 Along with the gained experience however, additional bad practices 136 have developed as well. Continuing the example above, the decision 137 to create a new application would result in the allocation of a new 138 application ID which often times is foreseen as cumbersome by 139 application designers because of the lengthy process. Designers 140 therefore tend to circumvent the better approach leading to many 141 compromises in the design that eventually lead to interoperability 142 issues (See Section 5.1). 144 The basic issue is that the rules defined in the Diameter Base 145 protocol are not comprehensive enough that one can easily derive good 146 design decisions from them. The effect of this can be seen in 147 various attempts to extend Diameter applications where designers have 148 no clear answer on whether to even define a new application or not. 149 At worst, some existing Diameter applications that had been purposely 150 derived from another existing application resulted in some in- 151 appropriate design decision where both the existing application and 152 the derived applications are no longer interoperable under certain 153 conditions. Note that it is not always possible to offer a complete 154 and concise answer to certain design choices, but at the least, this 155 document can be used as a guide to Diameter extensibility. 157 2. Terminology 159 This document reuses the terminology used in [1]. 161 3. Brief Overview of the Diameter Application Model 163 As it is currently interpreted and practiced, the Diameter Base 164 protocol is a two-layer protocol. The lower layer is mainly 165 responsible for managing connections between neighboring peers and 166 for message routing. The upper layer is where the Diameter 167 applications reside. This model is in line with a Diameter node 168 having an application layer and a peer-to-peer delivery layer. The 169 Diameter Base protocol document completely defines the architecture 170 and behavior of the message delivery layer and then provides the 171 framework for designing Diameter applications on the application 172 layer. This framework includes definitions of application sessions 173 and accounting support (see Section 8 and 9 of [1]). The remainder 174 of this document also treats a Diameter node as a single instance of 175 a Diameter message delivery layer and one or more Diameter 176 applications using it. 178 4. Rules on Extending Diameter 180 Extending Diameter can mean the reuse of commands, AVPs and AVP 181 values in any combination for the purpose of inheriting the features 182 of an existing Diameter applications. This section discusses the 183 rules on how such reuse can be done. 185 When reusing existing applications, the requirements of the new 186 applications are typically not completely unique and there are 187 existing applications that can be reused to solve some or all of the 188 new application requirements. Therefore, there is a greater 189 likelihood of ambiguity on how much of the existing application can 190 be reused and what would be the implications for both the new and 191 existing application. To broadly categorize, the rules for reusing 192 existing applications can be either: 194 1. Minimal - which typically means adding optional AVPs to existing 195 commands. 197 2. Invasive - where addition or deletion of commands and/or AVPs, 198 and/or AVP values (in the case where the AVP is of type 199 Enumerated). 201 Because it can fundamentally change the application, the latter 202 approach has strict repercussions. Specifically, it would result in 203 the definition of a new application and therefore allocation of a new 204 application ID is required. Discussion about the specific Diameter 205 Base protocol rules associated with this approach are covered 206 subsequent sections. 208 The former approach, although simple, has pitfalls. The problems 209 arise when there is a tendency by applications designers to keep 210 adding optional AVPs to existing command so they can circumvent the 211 rules associated with the latter approach. Specifically, some 212 designers want to circumvent the standardization process associated 213 with these rules and not necessarily the rules themselves. The 214 pitfalls associated with this approach are described further in 215 Section 4.2.1. Additionally, if designers choose this approach, all 216 of the functionality of the existing application will be inherited, 217 even if the new usage has no intent of using some of the existing 218 features. 220 4.1. Reusing Existing Applications 222 This section discusses the reuse of existing applications by adding 223 and/or deleting commands from the application. This scenario is 224 categorize as "Invasive" in Section 4 and would always result in the 225 creation of a new application when the rules are applied. 227 4.1.1. Adding a new command 229 The rules are strict in this case. Adding a command to an 230 application is not allowed and doing so will force a definition of a 231 new application. However, if this is the intent, then the new 232 application can be created by defining a new command for an existing 233 application or importing an existing command from another application 234 so as to inherit some or all of the functionality of that 235 application. In the former case, the decision is straightforward 236 since this is typically a result of adding new functionality that 237 does not yet exist. See Section 5.1 for rules on how to allocate new 238 command codes for new applications. The latter case would result in 239 a new application but it has a more subtle issue such as deciding 240 whether importing of commands and functionality is really better than 241 simply using the existing application as it is in conjunction with 242 any new application. 244 A typical example would be the Diameter MIPv6 split scenario (see 245 [2]) in which several application models would have been possible 246 during the design phase; one model would reuse existing Diameter EAP 247 application combined with a new Diameter MIPv6 application to form a 248 complete authentication and authorization scheme and another would be 249 to reuse Diameter EAP like commands within the new Diameter MIPv6 250 application to accomplish the same result. In this case, the latter 251 model was chosen which would permit the reuse of commands and/or AVPs 252 from one application to another. Other applications such as Diameter 253 QoS (see [3]) would likely face similar decisions. 255 In general, it is difficult to come to a hard and fast guideline, and 256 so a case by case study of each application requirement should be 257 applied. Before adding or importing a command, application designers 258 should consider the following: 260 o Can the new functionality be fulfilled by creating a new 261 application independent from the existing applications? In this 262 case, a deployment architecture could be designed such that both 263 old and new application can work independent of, but cooperating 264 with each other. 266 o Can the existing application be reused as is without fundamental 267 changes; e.g., a non-mandatory optional AVP is sufficient to 268 indicate support for new optional functionality, if any. There 269 are pitfalls to this approach as well. See Section 4.2.1 271 o Care should be taken to avoid a liberal method of importing many 272 commands that results in a monolithic and hard to manage 273 application which supports many different functionalities. 275 o Will the new feature or functionality refer only to semantic or 276 statemachine changes in the application requiring extra message 277 round-trips? In such cases, definition of new commands may not be 278 necessary and use of existing commands maybe sufficient. 280 o Reuse of existing applications would result in a distributed 281 environment which may not be conducive to certain requirements of 282 the applications; i.e. security and or deployment difficulties - 283 because of Diameter routing, messages for different applications 284 providing service to the same user may end up in different servers 285 would then need to be co-related. This could mean extra signaling 286 between application servers. A typical example would be the 287 initial proposal for Diameter MIPv6 split scenario (see [2]) where 288 authorization and authentication is separated. 290 Note that accounting commands normally require special treatment and 291 would not necessarily fall into this category. See Section 6.1. 293 4.1.2. Deleting a command 295 Although this is not typical, deleting an command from an existing 296 application is fundamentally changing the application. In general, 297 the implications of this approach are the same as Section 4.1.1 298 regardless of whether new commands will also be added to the 299 resulting application. In general, it is unusual to delete an 300 existing command from an existing application for the sake of 301 deleting it or the functionality it represents. This design decision 302 would normally be an indication of a flawed design. An exception 303 might be if the intent of the deletion is to create a newer version 304 of the same application which is somehow simpler than the previous 305 version. In that case, the considerations in Section 6.3 should 306 apply instead. 308 4.2. Reusing Existing Commands 310 This section deals with a little more granularity than Section 4.1. 311 Specifically, it discusses rules in adding and/or deleting AVPs from 312 an existing command of an existing application. Unlike Section 4.1, 313 the cases in this section may not necessarily result in the creation 314 of new application(s). In some cases, there are a lot of ambiguity. 315 So design considerations have been outlined to ease the decision 316 making process. 318 4.2.1. Adding AVPs to a command 320 Based on the rules in [1], AVPs that are added to an existing command 321 can be categorized into: 323 o Mandatory to understand AVPs. As defined in [1], these are AVPs 324 which has their M-bit flag set which means Diameter nodes that 325 receives these AVPs have to understand not only their values but 326 their semantics and usage as well. This is regardless of whether 327 these AVPs are required or optional to appear in the command; as 328 specified by the commands ABNF. See Section 6.4 for details on 329 the use of the M-bit. 331 o Non-mandatory AVPs that are also optional in the commands ABNF. 333 The rules are strict in the case where the AVPs to be added are 334 mandatory. A mandatory AVP cannot be added to or deleted from an 335 existing command. [1] states that doing so would require the 336 definition of a new application. This falls into the "Invasive" 337 category described in Section 4. Despite the clarity of the rule, 338 ambiguity still arises when trying to decide whether a new AVP being 339 added should be mandatory to begin with. There are several questions 340 that application designers should contemplate when trying to decide: 342 o Do the AVPs change the state machine of the application ? 344 o Would the presence of the AVPs cause additional message round- 345 trips; effectively changing the state machine of the application ? 347 o Will the AVP be used to fulfill new required functionality ? 349 o Would the AVP be used to differentiate between old and new 350 versions of the same application ? 352 o Will it have duality in meaning; i.e., be used to carry 353 application related information as well as be used to indicate 354 that the message is for a new application ? 356 If one or more of the above conditions are true, the AVP is 357 considered mandatory. These questions are not comprehensive in any 358 way, but in all cases the semantics of the application must change to 359 justify the use of mandatory AVPs. 361 The rules are less restrictive when adding non-mandatory, optional 362 AVPs. This falls into the "Minimal" category described in Section 4. 363 However, care should also be taken when opting for optional AVPs 364 instead of mandatory AVPs simply to avoid the process of creating a 365 new applications. Optional AVPs that answers any of the questions 366 above also have consequences. Some of the issues associated with 367 using optional AVPs are: 369 o Use of optional AVPs with intersecting meaning; one AVP has 370 partially the same usage and/or meaning as another AVP. The 371 presence of both can lead to confusion. 373 o An optional AVPs with dual purpose; i.e.; to carry applications 374 data as well as to indicate support for one or more features. 375 This has a tendency to introduce interpretation issues. 377 o Use of optional AVPs with a minimum occurrence of one(1) in the 378 command ABNF. This is generally contradictory. Application 379 designers should not use this scheme to circumvent definition of 380 mandatory AVPs. 382 o Adding one or more optional AVPs and indicating (usually within 383 descriptive text for the command) that at least one of them has to 384 be present in the command. This essentially circumventing the 385 ABNF and is equivalent to adding a mandatory AVPs to the command. 387 All of these practices generally result in interoperability problems 388 so they should be avoided as much as possible. 390 4.2.2. Deleting AVPs from a command 392 Although this scenario is not as common, the deletion of AVPs from a 393 command ABNF is significant when trying to extend an existing 394 application. Deletion can again be categorized between mandatory and 395 non-mandatory optional AVPs described in Section 4.2.1. 397 In the unlikely event that an application designer would require that 398 mandatory AVPs must be deleted then it constitutes a fundamental 399 change to an existing application. Though not specified in [1], 400 deletion of mandatory AVP would require the definition of a new 401 application since it dictates changes in the behavior and semantics 402 of an application. 404 Instead of deleting AVPs, a better alternative would be to define a 405 new command that would represent the new behavior. Reusing the same 406 command code for different use cases can lead to more confusion, 407 since the command will have different semantics depending on usage. 408 This is especially true to base protocol commands (session related 409 commands, ASR/ASA, STR/STA, RAR/RAA defined in [1]) where they are 410 being used by many different applications. 412 The deletion of an optional AVP may not necessarily require the 413 allocation of a new application. Deletion of non-mandatory optional 414 AVPs with a zero(0) minimum occurrence in the commands ABNF would not 415 require a new application. The case where an optional AVP has a 416 minimum occurrence of at least one(1) is unusual and not allowed in 418 [1]. However, there may be existing applications that do not follow 419 the new restrictions in [1]. These applications may have defined 420 optional AVPs with a minimum occurrence of at least one(1) in their 421 command ABNFs. In this case, the deletion of the AVP would 422 effectively change the behavior of the application. It would be 423 similar to the deletion of mandatory AVPs. Such cases are highly 424 dubious to begin with since those AVPs already exhibits properties of 425 mandatory AVPs. Extra consideration should be given as to why it was 426 not defined as mandatory in the first place and that decision may 427 have to be corrected as well. 429 In other cases, it is recommended that application designers reuse 430 the command ABNF without modification and simply ignore (but not 431 delete) any optional AVP that will not be used. This is to maintain 432 compatibility with existing applications that will not know about the 433 new functionality as well as maintain the integrity of existing 434 dictionaries. 436 4.3. Reusing Existing AVPs 438 This section deals with even more granularity than Section 4.1 and 439 Section 4.2. Specifically, it discusses rules in adding, deleting or 440 modifying the specified values and/or flags of an AVP. The rules 441 state that modifying the value of an AVP is allowed only if it does 442 not change the semantics of the AVP and the application using it. 443 Otherwise, the change can be consider "Invasive" as described in 444 Section 4 and require definition of a new application. Note that 445 designers should consider Section 5.2 when contemplating on these 446 types of changes. 448 Typically, the data types of the AVPs in question are scalar in 449 nature and each ordinal value represent a specific semantic behavior 450 of the application. An example is the CC-Request-Type AVP of [4]. 451 Adding, deleting or modifying known values of this AVP can modify the 452 behavior of the application itself, and additionally, the mandatory 453 and optional AVPs rules are inherited from Section 4.2. So this 454 affects the decision for defining new applications as well. 456 When reusing AVPs in a new application, the AVP flags such as the 457 mandatory flag ('M'-bit) can be modified (turned on or off) within 458 the application. In general, for AVPs defined outside of the base 459 protocol, its mandatory characteristics is tied to its role within an 460 application. Allowing the mandatory flag to be set or un-set by the 461 application(s) makes the AVP more reusable. Further details on the 462 mandatory flag ('M'-bit) can be found in Section 6.4. 464 5. Rules for new Applications 466 The general theme of Diameter extensibility is to reuse commands, 467 AVPs and AVP values as much as possible. However, some of the 468 extensibility rules described in the previous section also apply to 469 scenarios where a designer is trying to define a completely new 470 Diameter application. 472 This section discusses the case where new applications have 473 requirements that cannot be filled by existing applications and would 474 require definition of completely new commands, AVPs and/or AVP 475 values. Typically, there is little ambiguity about the decision to 476 create these types of applications. Some examples are the interfaces 477 defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([5] and 478 [6]), Sh ([7] and [8]) etc. 480 Application design should also follow the theme of Diameter 481 extensibility which in this case may mean the importing of existing 482 AVPs and AVP values for any newly defined commands. In certain cases 483 where accounting will be used, the models described in Section 6.1 484 should also be considered. Though some decisions may be clear, 485 designers should also consider certain aspects of defining a new 486 application. Some of these are described in following sections. 488 5.1. Rules in Allocating new Command Codes 490 If the protocol design justifies the allocation of a new command code 491 then a new application as well as a new application ID is required. 492 One of the drawbacks of [9] was that it required application 493 designers to go through a lengthy expert review process in order to 494 be allocated with a new command code(s). This restricts designers 495 who has to follow strict deadlines for delivering their applications. 496 Some designers eventually reverted to sub-optimal application design 497 to circumvent this restriction. To fix this issue, revisions 498 introduced in [1] has relaxed the process and introduced a vendor 499 specific command code space that can be allocated on a first-come 500 first-serve basis. 502 5.2. Justifying the Allocation of Application-Id 504 Application designers should avoid justifying the allocation of an 505 application ID for every new functionality or every minor change that 506 is made to an existing application. Proliferation of applications 507 that are very similar can lead to confusion. Application designers 508 should always use Section 4 as a basis for justifying allocation of a 509 new application ID. 511 5.3. Use of Application-Id in a Message 513 When designing new applications, designers should specify that the 514 application ID carried in all session level messages must be the 515 application ID of the application using those messages. This 516 includes the session level messages defined in base protocol, i.e., 517 RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled 518 accounting model, see Section 6.1. Existing specifications may not 519 adhere to this rule for historical or other reasons. However, this 520 scheme should be followed to avoid possible routing problems for 521 these messages. 523 In general, when a new application has been allocated with a new 524 application id and it also reuses existing commands with or without 525 modifications (Sec 4.1), it must use the newly allocated application 526 id in the header and in all relevant application id AVPs (Auth- 527 Application-Id or Acct-Application-Id) present in the commands 528 message body. 530 Additionally, application designs using 531 Vendor-Specific-Application-Id AVP should not use the Vendor-Id AVP 532 to further dissect or differentiate the vendor-specification 533 application id. The Vendor-Id should also not be used as an 534 additional input for routing or delivery of messages. In general, 535 the Vendor-Id AVP is an informational AVP only and kept for backward 536 compatibility reasons. 538 5.4. Application Specific Session Statemachine 540 Section 8 of [1] provides session statemachines for authentication, 541 authorization and accounting (AAA) services. When a new application 542 is being defined that cannot clearly be categorized into any of these 543 services it is recommended that the application itself define its own 544 session statemachine. The existing session statemachines defined by 545 [1] is not intended for general use beyond AAA services, therefore 546 any behavior not covered by that category would not fit well. 547 Support for server initiated request is a clear example where an 548 application specific session statemachine would be needed; i.e. Rw 549 interface for ITU-T push model. 551 5.5. End-to-End Applications Capabilities Exchange 553 It is also possible that applications can use optional AVPs to 554 exchange application specific capabilities and features. These AVPs 555 are exchanged on an end-to-end basis and understood only by the 556 application supporting them. The use of such AVPs must be limited to 557 convey application functionality. Examples of this can be found in 558 [2] and [3]. 560 This method can be used to resolve some of the problems described in 561 Section 6.3 and Section 6.2. It is also useful in providing some 562 restrictions and/or guidelines on the how the other functionality 563 related AVPs can be include in a command to avoid issues described in 564 Section 4.2.1. Such end-to-end capabilities AVPs can aid in the 565 following cases: 567 o Formalizing the way new functionality is added to existing 568 applications by announcing support for it. This makes determining 569 support for one or more specific functionality less ambiguous. 571 o Provide a way to further negotiate capabilities if allowed by the 572 applications. 574 o Applications that do not understand these AVP can discard it upon 575 receipt. In such case, senders of the AVP can also safely assume 576 the receiving end-point does not support any functionality carried 577 by the AVP if it is not present in subsequent responses. 579 Note that this list is not meant to be comprehensive. 581 6. Other Design Considerations 583 The following are some of the design considerations that apply to a 584 Diameter application. 586 6.1. Diameter Accounting Support 588 Accounting can be treated as an auxiliary application which is used 589 in support of other applications. In most cases, accounting support 590 is required when defining new applications. However, the lack of 591 clarity in the base protocol document has prevented easy use the base 592 accounting messages (ACR/ACA). This document provides two(2) 593 possible models for using accounting: 595 Split Accounting Model 597 In this model, the accounting messages will use the Diameter base 598 accounting application ID (value of 3). The design implication 599 for this is that the accounting is treated as an independent 600 application, especially during diameter routing. This means that 601 accounting commands emanating from an application may be routed 602 separately from the rest of the other application messages. This 603 also implies that the messages generally end up in a central 604 accounting server. A split accounting model is a good design 605 choice when: 607 * The application itself will not define its own unique 608 accounting commands. 610 * The overall system architecture permits the use of centralized 611 accounting for one or more Diameter applications. 613 Centralizing accounting may have advantages but there are also 614 drawbacks. The model assumes that the accounting server can 615 somehow differentiate received accounting messages. Since the 616 received accounting messages can be for any application and/or 617 service, the accounting server has to be have a method to uniquely 618 match accounting messages with applications and/or services being 619 accounted for. This may mean defining new AVPs, checking the 620 presence, absence or contents of existing AVPs or checking the 621 contents of the accounting records itself. But in general, there 622 is no clean and generic scheme for sorting these messages. 623 Therefore, the use of this model is recommended only when all 624 received accounting messages can be clearly identified and sorted. 625 For most cases, the use of Coupled Accounting Model is 626 recommended. 628 Coupled Accounting Model 630 In this model, the accounting messages will use the application ID 631 of the application using the accounting service. The design 632 implication for this is that the accounting messages are tightly 633 coupled with the application itself; meaning that accounting 634 messages will be routed like any other application messages. It 635 would then be the responsibility of the application server 636 (application entity receiving the ACR message) to send the 637 accounting records carried by the accounting messages to the 638 proper accounting server. The application server is also 639 responsible for formulating a proper response (ACA). A coupled 640 accounting model is a good design choice when: 642 * The system architecture or deployment will not provide an 643 accounting server that supports Diameter. 645 * The system architecture or deployment requires that the 646 accounting service for the specific application should be 647 handled by the application itself. 649 * The application server is provisioned to use a different 650 protocol to access the accounting server; i.e., via LDAP, XML 651 etc. This includes attempting to support older accounting 652 systems that are not Diameter aware. 654 In all cases above, there will generally be no direct Diameter 655 access to the accounting server. 657 These models provide a basis for using accounting messages. 658 Application designers may obviously deviate from these models 659 provided that the factors being addressed here have also been taken 660 into account. Though it is not recommended, examples of other 661 methods might be defining a new set of commands to carry application 662 specific accounting records. 664 6.2. Generic Diameter Extensions 666 Generic Diameter extensions are AVPs, commands or applications that 667 are designed to support other Diameter applications. They are 668 auxiliary applications meant to improve or enhance the Diameter 669 protocol itself or Diameter applications/functionality. Some 670 examples include the extensions to support auditing and redundancy 671 (see [12]), improvements in duplicate detection scheme (see [13]), 672 and piggybacking of QoS attributes (see [10]). 674 Since generic extensions can cover many aspects of Diameter and 675 Diameter applications, it is not possible to enumerate all the 676 probable scenarios in this document. However, some of the most 677 common considerations are as follows: 679 o Backward compatibility: Dealing with existing applications that do 680 not understand the new extension. Designers also have to make 681 sure that new extensions do not break expected message delivery 682 layer behavior. 684 o Forward compatibility: Making sure that the design will not 685 introduce undue restrictions for future applications. Future 686 applications attempting to support this feature should not have to 687 go through great lengths to implement any new extensions. 689 o Tradeoffs in signaling: Designers may have to choose between the 690 use of optional AVPs piggybacked onto existing commands versus 691 defining new commands and applications. Optional AVPs are simpler 692 to implement and may not need changes to existing applications; 693 i.e., use of proxy agents. However, the drawback is that the 694 timing of sending extension data will be tied to when the 695 application would be sending a message. This has consequences if 696 the application and the extensions have different timing 697 requirements. The use of commands and applications solves this 698 issue but the tradeoff is the additional complexity of defining 699 and deploying a new application. It is left up to the designer to 700 find a good balance among these tradeoffs based on the 701 requirements of the extension. 703 In practice, it is often the case that the generic extensions use 704 optional AVPs because it's simple and not intrusive to the 705 application that would carry it. Peers that do not support the 706 generic extensions need not understand nor recognize these optional 707 AVPs. However, it is recommended that the authors of the extension 708 specify the context or usage of the optional AVPs. As an example, in 709 the case that the AVP can be used only by a specific set of 710 applications then the specification must enumerate these applications 711 and the scenarios when the optional AVPs will be used. In the case 712 where the optional AVPs can be carried by any application, it is 713 should be sufficient to specify such a use case and perhaps provide 714 specific examples of applications using them. 716 In most cases, these optional AVPs piggybacked by applications would 717 be defined as a Grouped AVP and it would encapsulate all the 718 functionality of the generic extension. In practice, it is not 719 uncommon that the Grouped AVP will encapsulate an existing AVP that 720 has previously been defined as mandatory ('M'-bit set); i.e. 3GPP IMS 721 Cx / Dx interfaces ([5] and [6]). In previous revisions of the 722 Diameter base protocol, the Grouped AVP itself would also have to be 723 mandatory ('M'-bit set) which defeats the purpose of a non intrusive 724 optional AVP. This restriction has been lifted in the latest 725 revision of the Diameter base protocol. This gives more flexibility 726 to authors of generic extensions with regards to the use of optional 727 Grouped AVPs. 729 6.3. Updating an existing Application 731 An application that is being upgraded must follow the same rules 732 mentioned Section 4. Even if the new version is fundamentally the 733 same application, allocation of a new application ID is possible if 734 it meets those criteria. 736 Optional AVPs can also be used to indicate version differences. If 737 this approach is chosen, it is recommended that the optional AVP is 738 used specifically to indicate version information only and nothing 739 else. Additionally, the use of too many optional AVPs to carry 740 application enhancements should be avoided since such approach has a 741 tendency to become unmanageable and introduce interoperability 742 issues. These pitfalls are discussed in Section 4.2.1 744 For the same reason, care should be taken in attempting to justify 745 allocation of new application ID for every change. The pitfalls of 746 this approach is discussed in Section 5.3. 748 Acceptable techniques can be used to provide feature upgrades to 749 existing applications. One of these is described in Section 5.5. 751 6.4. Use of Mandatory (M-bit) flags 753 There has always been some confusion on the usage of an AVPs 754 mandatory flag, M-bit, especially when it relates to the optional or 755 required settings of the AVP within an ABNF. As a rule, the M-bit 756 specifies whether the receiver of the AVP is required to understand 757 and interpret the AVP and its content. This is regardless of whether 758 the AVP is optional to appear in a message or not. However, there is 759 some redundancy and overlap in this rule mainly because if the AVP is 760 non-optional in the ABNF then it is obvious that the application must 761 understands it. And even if the AVP is optional, i.e. it is defined 762 with "[AVP-Name]", it is reasonable to imply that the application 763 would have to understand this AVP since it is explicit about its 764 presence in the ABNF and even perhaps its usage. Given this, it is 765 reasonable to assume that the M-bit is set only for AVPs explicitly 766 appearing in an applications ABNF. The following practices can be 767 applied when deciding whether to set the mandatory (M-bit) flag on an 768 AVP: 770 o AVPs appearing explicitly in an applications ABNF must have it's 771 M-bit set. These application must have been allocated its own 772 application-Id. 774 o AVPs designed to be added to existing applications and not 775 explicitly appearing on those applications must not have its M-bit 776 set. These are AVPs defined outside of the applications that can 777 carry it. Examples can be found in [2], [11] and [10]. 779 This practice somewhat degrades the usefulness of the mandatory AVP 780 concept which may have flaws to begin with. However, it greatly 781 simplifies how to define which AVPs are required to be understood and 782 which are not. 784 6.5. System Architecture and Deployment 786 The following are some of the architecture considerations that 787 applications designers should contemplate when defining new 788 applications: 790 o For general AAA applications, Diameter requires more message 791 exchanges for the same set of services compared to RADIUS. 792 Therefore, application designers should consider scalability 793 issues during the design process. 795 o Application design should be agnostic to any Diameter topology. 796 Application designers should not always assume a particular 797 Diameter topology; i.e., assume that there will always be 798 application proxies in the path or assume that only intra-domain 799 routing is applicable. 801 o Security Considerations. Application designers should take into 802 account that there is no end-to-end authentication built into 803 Diameter. 805 o Application design should consider some form of redundancy. 806 Session state information is the primary data necessary for 807 backup/recovering endpoints to continue processing for an 808 previously existing session. Carrying enough information in the 809 messages to reconstruct session state facilitates redundant 810 implementations and is highly recommended. 812 o Application design should segregate message delivery layer 813 processing from application level processing. An example is the 814 use of timers to detect lack of a response for a previously sent 815 requests. Although the Diameter base protocol defines a watchdog 816 timer Tw, its use on application level is discouraged since Tw is 817 a hop-by-hop timer and it would not be relevant for end-to-end 818 message delivery error detection. In such a case, it is 819 recommended that applications should define their own set of 820 timers for such purpose. 822 o Applications should specify AVPs which could be used to further 823 aid in duplication detection. In some cases, when extending an 824 application, existing AVPs can be reused to provide additional 825 duplication detection indicators; i.e., combination of Session-Id 826 and CC-Request-Number AVPs in the Diameter Credit Control 827 application [4]. In cases where the extensions needs to define 828 new AVPs, it is recommended that the new AVPs be used only for 829 this purpose. 831 7. IANA Considerations 833 This document does not require actions by IANA. 835 8. Security Considerations 837 This document does provides guidelines and considerations for 838 extending Diameter and Diameter applications. It does not define nor 839 address security related protocols or schemes. 841 9. Acknowledgments 843 We greatly appreciate the insight provided by Diameter implementers 844 who have highlighted the issues and concerns being addressed by this 845 document. 847 10. References 849 10.1. Normative References 851 [1] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter 852 Base Protocol", draft-ietf-dime-rfc3588bis-10 (work in 853 progress), January 2008. 855 [2] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and 856 M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to 857 Diameter Server Interaction", draft-ietf-dime-mip6-split-06 858 (work in progress), November 2007. 860 [3] Zorn, G., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and 861 D. Sun, "Protocol for Diameter Quality of Service Application", 862 draft-ietf-dime-diameter-qos-02 (work in progress), 863 November 2007. 865 [4] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 866 Loughney, "Diameter Credit-Control Application", RFC 4006, 867 August 2005. 869 [5] 3GPP, "IMS Cx and Dx interfaces : signalling flows and message 870 contents", 3GPP TS 29.228 Version 7.0.0 2006. 872 [6] 3GPP, "IMS Cx and Dx interfaces based on the Diameter protocol; 873 Protocol details", 3GPP TS 29.229 Version 7.0.0 2006. 875 [7] 3GPP, "IMS Sh interface : signalling flows and message 876 content", 3GPP TS 29.328 Version 6.8.0 2005. 878 [8] 3GPP, "IMS Sh interface based on the Diameter protocol; 879 Protocol details", 3GPP TS 29.329 Version 6.6.0 2005. 881 [9] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 882 "Diameter Base Protocol", RFC 3588, September 2003. 884 [10] Korhonen, J., Tschofenig, H., Arumaithurai, M., and M. Jones, 885 "Quality of Service Attributes for Diameter", 886 draft-ietf-dime-qos-attributes-04 (work in progress), 887 January 2008. 889 [11] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and 890 K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access 891 Server to Diameter Server Interaction", 892 draft-ietf-dime-mip6-integrated-07 (work in progress), 893 November 2007. 895 10.2. Informative References 897 [12] Calhoun, P., "Diameter Resource Management Extensions", 898 draft-calhoun-diameter-res-mgmt-08.txt (work in progress), 899 March 2001. 901 [13] Asveren, T., "Diameter Duplicate Detection Cons.", 902 draft-asveren-dime-dupcons-00 (work in progress), August 2006. 904 Authors' Addresses 906 Victor Fajardo (editor) 907 Toshiba America Research Inc. 908 One Telcordia Drive, #1S222 909 Piscataway, NJ 08854 910 USA 912 Email: vfajardo@tari.toshiba.com 914 Tolga Asveren 915 Sonus Network 916 4400 Route 9 South 917 Freehold, NJ 07728 918 USA 920 Email: tasveren@sonusnet.com 922 Hannes Tschofenig 923 Nokia Siemens Networks 924 Otto-Hahn-Ring 6 925 Munich, Bavaria 81739 926 Germany 928 Phone: +49 89 636 40390 929 Email: Hannes.Tschofenig@nsn.com 930 URI: http://www.tschofenig.com 931 Glenn McGregor 932 Alcatel-Lucent 933 3461 Robin Ln Ste 1 934 Cameron Park, CA 95682 935 USA 937 Email: glenn@aaa.lucent.com 939 John Loughney 940 Nokia Research Center 941 955 Page Mill Road 942 Palo Alto, CA 94304 943 US 945 Phone: 1-650-283-8068 946 Email: john.loughney@nokia.com 948 Full Copyright Statement 950 Copyright (C) The IETF Trust (2008). 952 This document is subject to the rights, licenses and restrictions 953 contained in BCP 78, and except as set forth therein, the authors 954 retain all their rights. 956 This document and the information contained herein are provided on an 957 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 958 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 959 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 960 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 961 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 962 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 964 Intellectual Property 966 The IETF takes no position regarding the validity or scope of any 967 Intellectual Property Rights or other rights that might be claimed to 968 pertain to the implementation or use of the technology described in 969 this document or the extent to which any license under such rights 970 might or might not be available; nor does it represent that it has 971 made any independent effort to identify any such rights. Information 972 on the procedures with respect to rights in RFC documents can be 973 found in BCP 78 and BCP 79. 975 Copies of IPR disclosures made to the IETF Secretariat and any 976 assurances of licenses to be made available, or the result of an 977 attempt made to obtain a general license or permission for the use of 978 such proprietary rights by implementers or users of this 979 specification can be obtained from the IETF on-line IPR repository at 980 http://www.ietf.org/ipr. 982 The IETF invites any interested party to bring to its attention any 983 copyrights, patents or patent applications, or other proprietary 984 rights that may cover technology that may be required to implement 985 this standard. Please address the information to the IETF at 986 ietf-ipr@ietf.org. 988 Acknowledgment 990 Funding for the RFC Editor function is provided by the IETF 991 Administrative Support Activity (IASA).