draft-ietf-dime-app-design-guide-02.txt		draft-ietf-dime-app-design-guide-01.txt
	Diameter Maintanence and V. Fajardo, Ed.		Diameter Maintanence and V. Fajardo, Ed.
	Extensions (DIME) Toshiba America Research Inc.		Extensions (DIME) Toshiba America Research Inc.
	Internet-Draft T. Asveren		Internet-Draft T. Asveren
	Intended status: Informational Sonus Network		Intended status: Informational Sonus Network
	Expires: January 7, 2008 H. Tschofenig		Expires: December 8, 2007 H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	G. McGregor		G. McGregor
	Alcatel-Lucent		Alcatel-Lucent
	J. Loughney		J. Loughney
	Nokia Research Center		Nokia Research Center
	July 6, 2007		June 6, 2007
	Diameter Applications Design Guidelines		Diameter Applications Design Guidelines
	draft-ietf-dime-app-design-guide-02.txt		draft-ietf-dime-app-design-guide-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 41		skipping to change at page 1, line 41
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 7, 2008.		This Internet-Draft will expire on December 8, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Diameter Base protocol provides updated rules on how to extend		The Diameter Base protocol provides rules on how to extend Diameter
	Diameter by modifying and/or deriving from existing applications or		and to create new Diameter applications. This is a companion
	creating entirely new applications. This is a companion document to		document to clarify these rules. This document does not intended to
	the Diameter Base protocol which further explains and/or clarify		add, remove or change these rules, rather it helps protocol designers
	these rules. It is meant as a guidelines document and therefore it		to extend Diameter.
	does not add, remove or change existing rules.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Brief Overview of the Diameter Application Model . . . . . . . 4		3. Diameter Application Model . . . . . . . . . . . . . . . . . . 3
	4. Rules on Extending Diameter . . . . . . . . . . . . . . . . . 4		4. Rules on Diameter Extensibility . . . . . . . . . . . . . . . 4
	4.1. Reusing Existing Applications . . . . . . . . . . . . . . 5		4.1. Rules on Extending Existing Applications . . . . . . . . . 5
	4.1.1. Adding a new command . . . . . . . . . . . . . . . . . 6		5. Design Considerations . . . . . . . . . . . . . . . . . . . . 7
	4.1.2. Deleting a command . . . . . . . . . . . . . . . . . . 7		5.1. Diameter Accounting Support . . . . . . . . . . . . . . . 7
	4.2. Reusing Existing Commands . . . . . . . . . . . . . . . . 7		5.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 8
	4.2.1. Adding AVPs to a command . . . . . . . . . . . . . . . 7		5.3. Updating an existing Application . . . . . . . . . . . . . 9
	4.2.2. Deleting AVPs from a command . . . . . . . . . . . . . 9		5.4. Use of optional AVPs . . . . . . . . . . . . . . . . . . . 10
	4.3. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 10		5.5. Deleting AVPs from a Command ABNF . . . . . . . . . . . . 10
	5. Rules for new Applications . . . . . . . . . . . . . . . . . . 10		5.6. Justifying the Allocation of Application-Id . . . . . . . 11
	5.1. Rules in Allocating new Command Codes . . . . . . . . . . 10		5.7. Use of Application-Id in a Message . . . . . . . . . . . . 11
	5.2. Justifying the Allocation of Application-Id . . . . . . . 11		5.8. Application Specific Session Statemachine . . . . . . . . 11
	5.3. Use of Application-Id in a Message . . . . . . . . . . . . 11		5.9. System Architecture and Deployment . . . . . . . . . . . . 12
	5.4. Application Specific Session Statemachine . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	5.5. End-to-End Applications Capabilities Exchange . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. Other Design Considerations . . . . . . . . . . . . . . . . . 12		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	6.1. Diameter Accounting Support . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.2. Generic Diameter Extensions . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	6.3. Updating an existing Application . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	6.4. System Architecture and Deployment . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The Diameter Base protocol document defines rules on how one would		The Diameter Base protocol document defines rules on how one would
	extend Diameter (see Section 1.2 of [1]). In the context of this		extend Diameter (see Section 1.2 of [1]). In the context of this
	document, extending Diameter means one of the following:		document, extending Diameter means that a new Diameter application is
			being defined which may or may not be based on an existing Diameter
	1. A new functionality is being added to an existing Diameter		application. A decision to define a new application would mean
	application without defining a new application.		allocation of a new application ID.
	2. A new Diameter application is being defined by reusing an
	existing application.
	3. A completely new application is being defined that has no
	dependencies to any existing applications.
	4. A new generic functionality is being defined that can be reused		By themselves, the rules defined in the Diameter Base protocol are
	across different applications.		not necessarily comprehensive enough that one can easily derive good
			design decisions from them. The effect of this can be seen in
			various attempts to extend Diameter where protocol designers have no
			clear answer on whether to even define a new application or not. At
			worst, some existing Diameter applications that had purposely been
			derived from another existing application resulted in some in-
			appropriate design decision in which both applications are no longer
			interoperable in certain conditions.
	All of these choices are design decisions that can done by any		The intent of this document is to influence ongoing and future
	combination of reusing existing or defining new commands, AVPs or AVP		Diameter application design by providing the following content:
	values. The objective of this document is the following:
	o Clarify updated Diameter extensibility rules in the Diameter Base		o Clarify existing Diameter extensibility rules present in the
	Protocol.		Diameter Base Protocol.
	o Clarify usage of certain Diameter functionality which are not		o Clarify usage of certain Diameter functionality which are not
	explicitly described in the Diameter Base specification.		explicitly described in the Diameter Base specification.
	o Discuss design choices and provide guidelines when defining		o Discuss design choices when defining new applications.
	applications.
	o Present tradeoffs of design choices.		o Present tradeoffs of design choices.
	These guidelines are necessary since the existing rules do not cover		Note that it is not always possible to offer a complete and concise
	the ambiguity that exist when some of the design choices overlap. A		answer to certain design choices. There is, however, the belief that
	typical example would be deciding between item one(1) and two(2)		at a minimum, this document can be used as a guide to Diameter
	above when an application designer requires a new application		extensibility.
	functionality which has many things in common with an existing
	application. Certain ambiguous aspects of such cases was not
	foreseen in the existing extensibility rules; i.e., use of optional
	AVPs to differentiate new functionality in the old application versus
	defining a new application and importing the existing set of
	commands. In this example, it was only based on collective
	experiences of application designers that the decision to create a
	new application (item two(2)) is now seen as the cleanest approach.
	Along with the gained experience however, additional bad practices
	have developed as well. Continuing the example above, the decision
	to create a new application would result in the allocation of a new
	application ID which often times is foreseen as cumbersome by
	application designers because of the lengthy process. Designers
	therefore tend to circumvent the better approach leading to many
	compromises in the design that eventually lead to interoperability
	issues (See Section 5.1).
	The basic issue is that the rules defined in the Diameter Base
	protocol are not comprehensive enough that one can easily derive good
	design decisions from them. The effect of this can be seen in
	various attempts to extend Diameter applications where designers have
	no clear answer on whether to even define a new application or not.
	At worst, some existing Diameter applications that had purposely been
	derived from another existing application resulted in some in-
	appropriate design decision where both the existing application and
	the derived applications are no longer interoperable under certain
	conditions. Note that it is not always possible to offer a complete
	and concise answer to certain design choices but at the least, this
	document can be used as a guide to Diameter extensibility.
	2. Terminology		2. Terminology
	This document reuses the terminology used in [1].		This document reuses the terminology used in [1].
	3. Brief Overview of the Diameter Application Model		3. Diameter Application Model
	As it is currently interpreted and practiced, the Diameter Base		As it is currently interpreted and practiced, the Diameter Base
	protocol is a two-layer protocol. The lower layer is mainly		protocol is a two-layer protocol. The lower layer is mainly
	responsible for managing connections between neighboring peers and		responsible for managing connections between neighboring peers and
	for message routing. The upper layer is where the Diameter		for message routing. The upper layer is where the Diameter
	applications reside. This model is inline with a Diameter node		applications reside. This model is inline with a Diameter node
	having an application layer and a peer-to-peer delivery layer. The		having an application layer and a peer-to-peer delivery layer. The
	Diameter Base protocol document completely defines the architecture		Diameter Base protocol document completely defines the architecture
	and behavior of the message delivery layer and then provides the		and behavior of the message delivery layer and then provides the
	framework for designing Diameter applications on the application		framework for designing Diameter applications on the application
	layer. This framework includes definitions of application sessions		layer. This framework includes definitions of application sessions
	and accounting support (see Section 8 and 9 of [1]). The remainder		and accounting support (see Section 8 and 9 of [1]). The remainder
	of this document also treats a Diameter node as a single instance of		of this document also treats a Diameter node as a single instance of
	a Diameter message delivery layer and one or more Diameter		a Diameter message delivery layer and one or more Diameter
	applications using it.		applications using it.
	4. Rules on Extending Diameter		4. Rules on Diameter Extensibility
	Extending Diameter can mean the reuse of commands, AVPs and AVP
	values in any combination for the purpose of inheriting the features
	of an existing Diameter applications. This section discusses the
	rules on how such reuse can be done.
	When reusing existing applications, the requirements of the new
	applications are typically not completely unique and there are
	existing application's that can be reused to solve some or all of the
	application requirements. Therefore, there is a greater likelihood
	of ambiguity on how much of the existing application can be reused,
	to what extent and what the implications for both the new and
	existing application. To broadly categorize, the rules for reusing
	existing applications can be either:
	1. Minimal - which typically means adding optional AVPs to existing
	commands.
	2. Invasive - where addition or deletion of commands and/or AVPs,
	and/or AVP values.
	Because it can fundamentally change the application, the latter
	approach has strict repercussions. Specifically, it would result in
	the definition of a new application and therefore allocation of a new
	application ID is required. Discussion about the specific Diameter
	Base protocol rules associated with this approach are covered
	subsequent sections.
	The former approach, although simple, has pitfalls. The problems
	arise when there is a tendency by applications designers to keep
	adding optional AVPs to existing command so they can circumvent the
	rules associated with the latter approach. Specifically, some
	designers want to circumvent the standardization process associated
	with these rules and not necessarily the rules themselves. The
	pitfalls associated with this approach is described further in
	Section 4.2.1. Additionally, if designers choose this approach, all
	of the functionality of the existing application will be inherited
	even if the new usage has no intent of using some of the existing
	features.
	4.1. Reusing Existing Applications
	This section discusses the reuse of existing applications by adding
	and/or deleting commands from the application. This scenario is
	categorize as "Invasive" in Section 4 and would always result in the
	creation of new applications when the rules are applied.
	4.1.1. Adding a new command
	The rules are strict in this case. Adding a command to an
	application is not allowed and doing so will force a definition of a
	new application. However, if this is the intent, then the new
	application can be created by defining a new command for an existing
	application or importing an existing command from another application
	so as to inherit some or all of the functionality of that
	application. In the former case, the decision is straight forward
	since this is typically a result of adding new functionality that
	does not yet exist. See Section 5.1 for rules on how to allocate new
	command codes for new applications. The latter case would result in
	a new application but it has a more subtle issue such as deciding
	whether importing of commands and functionality is really better than
	simply using the existing application as it is in conjunction with
	any new application.
	A typical example would be the Diameter MIPv6 split scenario (see
	[2]) in which several application models would have been possible
	during the design phase; one model would reuse existing Diameter EAP
	application combined with a new Diameter MIPv6 application to form a
	complete authentication and authorization scheme and another would be
	to reuse Diameter EAP like commands within the new Diameter MIPv6
	application to accomplish the same result. In this case, the latter
	model was chosen which would permit the reuse of commands and/or AVPs
	from one application to another. Other applications such as Diameter
	QoS (see [3]) would likely face similar decisions.
	In general, it is difficult to come to a hard and fast guideline so a
	case by case study of each application requirement should be applied.
	Before adding or importing a command, application designers should
	consider the following:
	o Can the new functionality be fulfilled by creating a new
	application independent from the existing applications ? In this
	case, a deployment architecture could be designed such that both
	old and new application can work independent of but cooperating
	with each other.
	o Can the existing application be reused as is without fundamental
	changes; i.e. a non-mandatory optional AVP is sufficient to
	indicate support for new optional functionality if any. There are
	pitfalls to this as well. See Section 4.2.1
	o Care should be taken to avoid a liberal method of importing many		The general theme of Diameter extensibility is to reuse AVPs, AVP
	commands that results in a monolithic and hard to manage		values, commands and applications as much as possible. However,
	application which supports many different functionality.		there are also rules for extending Diameter as specified in Section
			1.2 of [1]. As is, the rules apply to the scenario where one is
			trying to define a new Diameter application. Defining a new Diameter
			application can be done by:
	o Will the new feature or functionality refers only to semantic or		Defining a completely new application
	statemachine changes in the application requiring extra message
	round-trips ? In such cases, definition of new commands may not
	be necessary and use of existing commands maybe sufficient.
	o Reuse of existing applications would result in a distributed
	environment which may not be conducive to certain requirements of
	the applications; i.e. security and or deployment difficulties -
	because of Diameter routing, messages for different applications
	providing service to the same user may end up in different servers
	would then need to be co-related. This could mean extra signaling
	between application servers. A typical example would be the
	initial proposal for Diameter MIPv6 split scenario (see [2]) where
	authorization and authentication is separated.
	Note that accounting commands normally require special treatment and		This case applies to applications which have requirements that
	would not necessarily fall into this category. See Section 6.1.		cannot be filled by existing applications and would require
			definition of new command(s), AVPs and AVP values. Typically,
			there is little ambiguity about the decision to create these types
			of applications. Some examples are the interfaces defined for the
			IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([2] and [3]), Sh
			([4] and [5]) etc . Though some decisions may be clear, designers
			should also consider certain aspects of the application itself.
			Some of these are described in Section 5. Applications design
			should also follow the theme of Diameter extensibility which
			advocates reuse of AVPs and AVP values as much as possible even in
			newly defined commands. In certain cases where accounting will be
			used, the models described in Section 5.1 should be considered.
	4.1.2. Deleting a command		Extending an existing application
	Although this is not typical, deleting an command from an existing		In this case, the requirements of the new applications are not
	application is fundamentally changing the application. In general,		completely unique and there are existing application's that can be
	the implications of this approach is the same as Section 4.1.1		reused to solve some or all of the application requirements.
	regardless of whether new commands will also be added to the		Thus, there is a greater likelihood of ambiguity on how much of
	resulting application. In general, it is unusual to delete an		the existing application can be reused, to what extent and what
	existing command from an existing for the sake of deleting it or the		the implications for both the new and existing application.
	functionality it represents. This design decision would normally be		Section 4.1 discusses some of the issues in this case.
	an indication of a flawed designed. An exception might be if the
	intent of the deletion is to create a newer version of the same
	application which is somehow simpler than the previous version. In
	that case, the considerations in Section 6.3 should apply instead.
	4.2. Reusing Existing Commands		4.1. Rules on Extending Existing Applications
	This section deals with a little more granularity than Section 4.1.		The Diameter base protocol provides a clear set of rules on when one
	Specifically, it discusses rules in adding and/or deleting AVPs from		should define a new Diameter application. In the context of this
	an existing command of an existing application. Unlike Section 4.1,		document, the rules are:
	the cases in this section may not necessarily result in the creation
	of new application(s). In some cases, there are a lot of ambiguity.
	So design considerations have been outline to ease the decision
	making process.
	4.2.1. Adding AVPs to a command		Adding an AVP to a command ABNF of an existing application
	Based on the rules in [1], AVPs that are added to an existing command		The rules are strict in the case where the AVP(s) to be added is
	can be categorized into:		mandatory. As defined in [1], a mandatory AVP is an AVP that has
	o Mandatory to understand AVPs. As defined in [1], these are AVPs		its M-bit flag set which requires a receiver to understand,
	which has their M-bit flag set which means Diameter nodes that		correctly interpret and process the AVP when it is present in a
	receives these AVPs has to understand not only their values but		message. This rule is independent of whether the AVP is defined
	their semantics and usage as well. This is regardless of whether		as required or optional to exist in a message. As long as the AVP
	these AVPs are required or optional to appear in the command; as		will added to a messages' ABNF then this rule will apply.
	specified by the commands ABNF.
	o Non-mandatory AVPs that are also optional in the commands ABNF.
	The rules are strict in the case where the AVPs to be added is		The mandatory AVP rules applies to AVP(s) that either already
	mandatory. A mandatory cannot be added to or deleted from an		exist in the same or in another application or the AVP(s) are yet
	existing command. [1] states that doing so would require the		to be defined. The ambiguity arises when trying to decide whether
	definition of a new application. This falls into the "Invasive"		the AVP(s) should be mandatory or not. There are several
	category described in Section 4. Despite the clarity of the rule,		questions that application designers should contemplate when
	ambiguity still arises when trying to decide whether a new AVP being		trying to decide:
	added should be mandatory to begin with. There are several questions
	that application designers should contemplate when trying to decide:
	o Does the AVPs change the state machine of the application ?		* Does the AVP(s) change the state machine of the application ?
	o Would the presence of the AVPs cause additional message round-		* Would the presence of the AVP(s) cause additional message
	trips; effectively changing the state machine of the application ?		round-trips; effectively changing the state machine of the
			application ?
	o Will the AVP be used to fulfill new required functionality ?		* Will the AVP be used to fulfill new required functionality ?
	o Would the AVP be used to differentiate between old and new		* Would the AVP be used to differentiate between old and new
	versions of the same application ?		versions of the same application ?
	o Will it have duality in meaning; i.e., be used to carry		* Will it have duality in meaning; i.e., be used to carry
	application related information as well as be used to indicate		application related information as well as be used to indicate
	that the message is for a new application ?		that the message is for a new application ?
	If one or more of the above conditions are true, the AVP is consider		These questions are not comprehensive in any way but in all cases
	mandatory. These questions are not comprehensive in any way but in		the semantics of the application must change to justify the use of
	all cases the semantics of the application must change to justify the
	use of mandatory AVPs.
	The rules are less restrictive when adding Non-mandatory, optional
	AVPs. This falls into the "Minimal" category described in Section 4.
	However, care should also be taken when opting for optional AVPs
	instead of mandatory AVPs simply to avoid the process of creating a
	new applications. Optional AVPs that answers any of the questions
	above also have consequences. Some of the issues associated with
	using optional AVPs are:
	o Use of optional AVPs with intersecting meaning; one AVP has
	partially the same usage and/or meaning as another AVP. The
	presence of both can lead to confusion.
	o An optional AVPs with dual purpose; i.e.; to carry applications
	data as well as to indicate support for one or more features.
	This has a tendency to introduce interpretation issues.
	o Use of optional AVPs with a minimum occurrence of one(1) in the
	command ABNF. This is generally contradictory. Application
	designers should not use this scheme to circumvent definition of
	mandatory AVPs.		mandatory AVPs.
	All of these practices generally result in interoperability problems		However, care should also be taken when opting for optional AVPs
	so they should be avoided as much as possible.		instead of mandatory AVPs simply to avoid allocating new
			applications. Optional AVPs that fall into any of the categorical
	4.2.2. Deleting AVPs from a command		questions above would have consequences. See Section 5.4 for
			details.
	Although this scenario is not as common, the deletion of AVPs from a
	command ABNF is significant when trying to extend an existing
	application. Deletion can again be categorized between mandatory and
	non-mandatory optional AVPs described in Section 4.2.1.
	In the unlikely event that an application designer would require that
	mandatory AVPs must be deleted then it constitutes a fundamental
	change to an existing application. Though not specified in [1],
	deletion of mandatory would require the definition of a new
	application since it dictates changes in the behavior and semantics
	of an application.
	Instead of deleting commands, a better alternative would be to define
	a new command that would represent the new behavior. Reusing the
	same command code for different use cases can lead to more confusion
	since the command will have different semantics depending on usage.
	This is especially true to base protocol commands (session related
	commands, ASR/ASA, STR/STA, RAR/RAA defined in [1]) where they are
	being used by many different applications.
	The deletion of an optional AVP may not necessarily indicate
	allocation of a new application. Deletion of non-mandatory optional
	AVPs with a zero(0) minimum occurrence in the commands ABNF would not
	require a new application. In the case where an optional AVP has a
	minimum occurrence of at least one(1) in the commands ABNF, then
	deletion of the AVP would effectively change the behavior of the
	application. It would be similar to the deletion of mandatory AVPs.
	Such cases are highly dubious to begin with since those AVPs already
	exhibits properties of mandatory AVPs. Extra consideration should be
	given as to why it was not defined as mandatory in the first place
	and that decision may have to be corrected as well.
	In other cases, it is recommended that application designers reuse
	the command ABNF without modification and simply ignore (but not
	delete) any optional AVP that will not be used. This is to maintain
	compatibility with existing applications that will not know about the
	new functionality as well as maintain the integrity of existing
	dictionaries.
	4.3. Reusing Existing AVPs
	This section deals with even more granularity than Section 4.1 and
	Section 4.2. Specifically, it discusses rules in adding, deleting or
	modifying the specified values of an AVP. The rules state that
	modifying the value of an AVP is allowed only if it does not change
	the semantics of the AVP and the application using it. Otherwise,
	the change can be consider "Invasive" as described in Section 4 and
	require definition of a new application. Note that designers should
	consider Section 5.2 when contemplating on these types of changes.
	Typically, the data types of the AVPs in question are scalar in
	nature and each ordinal value represent a specific semantic behavior
	of the application. An example is CC-Request-Type AVP of [4].
	Adding, deleting or modifying known values of this AVP can modify the
	behavior of the application itself. Additionally, the mandatory and
	optional AVPs rules are inherited from Section 4.2. So this affects
	the decision for defining new applications as well.
	5. Rules for new Applications
	The general theme of Diameter extensibility is to reuse commands,
	AVPs and AVP values as much as possible. However, some of the
	extensibility rules described in the previous section also apply to
	scenarios where a designer is trying to define a completely new
	Diameter application.
	This section discusses the case where new applications have
	requirements that cannot be filled by existing applications and would
	require definition of completely new commands, AVPs and/or AVP
	values. Typically, there is little ambiguity about the decision to
	create these types of applications. Some examples are the interfaces
	defined for the IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([5] and
	[6]), Sh ([7] and [8]) etc.
	Application design should also follow the theme of Diameter
	extensibility which in this case may mean importing of existing AVPs
	and AVP values for any newly defined commands. In certain cases
	where accounting will be used, the models described in Section 6.1
	should also be considered. Though some decisions may be clear,
	designers should also consider certain aspects of defining a new
	application. Some of these are described in following sections.
	5.1. Rules in Allocating new Command Codes
	[Editor's note: The expert review process for command code allocation
	is being introduced to hasten the allocation process itself.
	Hopefully this will lessen the tendency to circumvent this process.
	The core rules for this process will be introduced in rfc3588bis and
	full description will be added in this section in the next rev of
	this document]
	5.2. Justifying the Allocation of Application-Id
	Application designers should avoid justifying the allocation of an
	application ID for each new functionality or any change that is made
	to an existing application. Proliferation of application ID can lead
	to confusion and an in-efficient use of the application ID
	namespaces. Application designers should always use Section 4 as a
	basis for justifying allocation of a new application ID.
	5.3. Use of Application-Id in a Message
	When designing new applications, designers should specify that the
	application ID carried in all session level messages must be the
	application ID of the application using those messages. This
	includes the session level messages defined in base protocol, i.e.,
	RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled
	accounting model, see Section 6.1. Existing specifications may not
	adhere to this rule for historical or other reasons. However, this
	scheme is followed to avoid possible routing problems for these
	messages.
	Additionally, application designers using the Vendor-Specific-
	Application-Id AVP should note that the Vendor-Id AVP will not be
	used in any way by the Diameter message delivery layer. Therefore
	its meaning and usage should be segregated only within the
	application.
	5.4. Application Specific Session Statemachine
	Section 8 of [1] provides session statemachines for authentication,		Add a new AVP value to an to an existing AVP
	authorization and accounting (AAA) services. When a new application
	is being defined that cannot clearly be categorized into any of these
	services it is recommended that the application itself defines its
	own session statemachine. The existing session statemachines defined
	by [1] is not intended for general use beyond AAA services therefore
	any behavior not covered by that category would not fit well.
	Support for server initiated request is a clear example where an
	application specific session statemachine would be needed; i.e. Rw
	interface for ITU-T push model.
	5.5. End-to-End Applications Capabilities Exchange		In this case, the rule applies to existing mandatory AVPs already
			present in a command ABNF where the semantics of the AVP changes.
			This means that the meaning or usage of the AVP has changed and
			significantly affects the behavior of the application. Although
			this case may be less common or seem more subtle, the exact same
			considerations given in the first scenario above apply here as
			well.
	It is also possible that applications can use a type of optional		Add a command to an existing application
	capabilities exchange AVPs as a way to convey support for specific
	application features. These AVPs are exchanged on an end-to-end
	basis and known only by the application supporting them. The use of
	such AVPs must obviously be limited to convey functionality of the
	applications itself. Examples of this can be found in [2] and [3].
	This method can be used to resolve some of the problems described in		In this case, the rule applies to defining a new command for an
	Section 6.3 and Section 6.2. It is also useful in providing some		existing application or importing an existing command from another
	restrictions and/or guidelines on the how the other functionality		application so as to inherit some or all of the functionality of
	related AVPs can be include in a command to avoid issues described in		that application. In the first case, the decision is straight
	Section 4.2.1. Such end-to-end capabilities AVPs can aid in the		forward since this is typically a result of adding new
	following cases:		functionality that does not yet exist. The latter case would
			result in a new application but it has a more subtle issue such as
			deciding whether importing of commands and functionality is really
			better than simply using the existing application as it is in
			conjunction with any new application.
	o Formalizing the way new functionality is added to existing		A typical example would be the Diameter MIPv6 split scenario (see
	applications by announcing support for it. This makes determining		[6]) in which several application models would have been possible
	support for one or more specific functionality less ambiguous.		during the design phase; one model would reuse existing Diameter
			EAP application combined with a new Diameter MIPv6 application to
			form a complete authentication and authorization scheme and
			another would be to reuse Diameter EAP like commands within the
			new Diameter MIPv6 application to accomplish the same result. In
			this case, the latter model was chosen which would permit the
			reuse of commands and/or AVPs from one application to another.
			Other applications such as Diameter QoS (see [7]) would likely
			face similar decisions.
	o Provide a way to further negotiate capabilities if allowed by the		In general, it is difficult to come to a hard and fast guideline
	applications.		for this scenario so a case by case study of each application
			requirement should be applied. Before importing a command,
			application designers should consider whether:
	o Applications that do not understand the capabilities AVP can		* The existing application can be reused as is without
	safely ignore it upon receipt. In such case, senders of the AVP		fundamental changes; i.e. an optional AVP is sufficient to
	can also safely assume the receiving end-point does not support		indicate support for new optional functionality if any. There
	any functionality carried by the AVP if it is not present in		are pitfalls to this as well. See Section 5.4
	subsequent responses.
	Note that this list is not meant to be comprehensive.		* Reuse of existing applications would result in a distributed
			environment which may not be conducive to certain requirements
			of the applications; i.e. security and or deployment
			difficulties - because of Diameter routing, messages for
			different applications providing service to the same user may
			end up in different servers would then need to be co-related.
			This could mean extra signaling between application servers. A
			typical example would be the initial proposal for Diameter
			MIPv6 split scenario (see [6]) where authorization and
			authentication is separated.
	6. Other Design Considerations		5. Design Considerations
	The following are some of the design considerations that apply to a		The following are some of the design considerations that apply to a
	Diameter application.		Diameter application.
	6.1. Diameter Accounting Support		5.1. Diameter Accounting Support
	Accounting can be treated as an auxiliary application which is used		Accounting can be treated as an auxiliary application which is used
	in support of other applications. In most cases, accounting support		in support of other applications. In most cases, accounting support
	is required when defining new applications. However, the lack of		is required when defining new applications. However, the lack of
	clarity in the base protocol document has prevented easy use the base		clarity in the base protocol document has prevented easy use the base
	accounting messages (ACR/ACA). This document provides two(2)		accounting messages (ACR/ACA). This document provides two(2)
	possible models for using accounting:		possible models for using accounting:
	Split Accounting Model		Split Accounting Model
	skipping to change at page 14, line 26		skipping to change at page 8, line 47
	into account. Though it is not recommended, examples of other		into account. Though it is not recommended, examples of other
	methods would be defining a new set of commands to carry application		methods would be defining a new set of commands to carry application
	specific accounting records.		specific accounting records.
	Additionally, the application ID in the message header and		Additionally, the application ID in the message header and
	Accounting-Application-Id AVP are populated depending on the		Accounting-Application-Id AVP are populated depending on the
	accounting model used for a specific application, as described in		accounting model used for a specific application, as described in
	[1]. Therefore, application designers have to specify the accounting		[1]. Therefore, application designers have to specify the accounting
	model used to guarantee proper routing of accounting requests.		model used to guarantee proper routing of accounting requests.
	6.2. Generic Diameter Extensions		5.2. Generic Diameter Extensions
	Generic Diameter extensions are AVPs, commands or applications that		Generic Diameter extensions are AVPs, commands or applications that
	are designed to support other Diameter applications. They are		are designed to support other Diameter applications. They are
	auxiliary applications meant to improve or enhance the Diameter		auxiliary applications meant to improve or enhance the Diameter
	protocol itself or Diameter applications/functionality. Some		protocol itself or Diameter applications/functionality. Some
	examples include the extensions to support auditing and redundancy		examples include the extensions to support auditing and redundancy
	(see [9]), improvements in duplicate detection scheme (see [10]).		(see [9]), improvements in duplicate detection scheme (see [10]).
	Since generic extensions can cover many aspects of Diameter and		Since generic extensions can cover many aspects of Diameter and
	Diameter applications, it is not possible to enumerate all the		Diameter applications, it is not possible to enumerate all the
	skipping to change at page 15, line 15		skipping to change at page 9, line 36
	i.e., use of proxy agents. However, the drawback is that the		i.e., use of proxy agents. However, the drawback is that the
	timing of sending extension data will be tied to when the		timing of sending extension data will be tied to when the
	application would be sending a message. This has consequences if		application would be sending a message. This has consequences if
	the application and the extensions have different timing		the application and the extensions have different timing
	requirements. The use of commands and applications solves this		requirements. The use of commands and applications solves this
	issue but the tradeoff is the additional complexity of defining		issue but the tradeoff is the additional complexity of defining
	and deploying a new application. It is left up to the designer to		and deploying a new application. It is left up to the designer to
	find a good balance among these tradeoffs based on the		find a good balance among these tradeoffs based on the
	requirements of the extension.		requirements of the extension.
	6.3. Updating an existing Application		5.3. Updating an existing Application
	An application that is being upgraded must follow the same rules		An application that is being upgraded must follow the same rules
	mentioned Section 4. Even if the new version is fundamentally the		mentioned Section 4. Even if the new version is fundamentally the
	same application, allocation of a new application ID is possible if		same application, allocation of a new application ID is possible if
	it meets those criteria.		it meets those criteria.
	Optional AVPs can also be used to indicate version differences. If		Optional AVPs can also be used to indicate version differences. If
	this approach is chosen, it is recommended that the optional AVP is		this approach is chosen, it is recommended that the optional AVP is
	used specifically to indicate version information only and nothing		used specifically to indicate version information only and nothing
	else. Additionally, the use of too many optional AVPs to carry		else. Additionally, the use of too many optional AVPs to carry
	application enhancements should be avoided since such approach has a		application enhancements should be avoided since such approach has a
	tendency to become unmanageable and introduce interoperability		tendency to become unmanageable and introduce interoperability
	issues. These pitfalls are discussed in Section 4.2.1		issues. These pitfalls are discussed in Section 5.4
	For the same reason, care should be taken in attempting to justify		For the same reason, care should be taken in attempting to justify
	allocation of new application ID for every change. The pitfalls of		allocation of new application ID for every change. The pitfalls of
	this approach is discussed in Section 5.3.		this approach is discussed in Section 5.6.
	Acceptable techniques can be used to provide feature upgrades to		5.4. Use of optional AVPs
	existing applications. One of these is described in Section 5.5.
	6.4. System Architecture and Deployment		Problems arise when there is a tendency by applications designers to
			keep adding optional AVPs to an existing command so they can
			circumvent the extension rules in Section 4. Some of the pitfalls
			that application designers should avoid are:
			o Use of optional AVPs with intersecting meaning; one AVP has
			partially the same usage and/or meaning as another AVP. The
			presence of both can lead to confusion.
			o Optional AVPs with dual purpose; i.e.; to carry applications data
			as well as to indicate support for one or more features. This has
			a tendency to introduce interpretation issues.
			o Use of optional AVPs with a minimum occurrence of one(1) in the
			command ABNF. This is generally contradictory. Application
			designers should not use this scheme to circumvent definition of
			mandatory AVPs.
			All of these practices generally result in interoperability problems
			so they should be avoided as much as possible.
			5.5. Deleting AVPs from a Command ABNF
			Although this scenario is not as common, the deletion of AVPs from a
			command ABNF is significant when trying to extend an existing
			application. Deletion can be categorized between deletion of
			mandatory and optional AVPs.
			In the unlikely event that an application designer would require that
			mandatory AVPs must be deleted then it constitutes a fundamental
			change to an existing application. Though not specified in [1],
			deletion of mandatory would most likely require the allocation of a
			new application since it dictates changes in the behavior and
			semantics of an application.
			Additionally, it is highly recommended that a new command code be
			defined that would represent the new behavior. Reusing the same
			command code would lead to more confusion since the command will have
			different semantics depending usage or context. This applies
			especially to some of the base protocol commands (session related
			commands defined in [1]) where they are being used by many different
			applications.
			The deletion of an optional AVP may not necessarily indicate
			allocation of a new application. An optional AVP with a minimum
			occurrence of at least one(1) in the command ABNF would mean that the
			AVP is required and that if deleted, there would effectively be
			changes to the behavior of the application as well. Such cases are
			highly dubious to begin with since those AVPs already exhibits
			properties of mandatory AVPs. It should therefore fall into the
			category of deleting mandatory AVPs.
			In other cases, it is recommended that application designers reuse
			the command ABNF as is and safely ignore (but not delete) any
			optional AVP that will not be used. This is to maintain
			compatibility with existing applications that will not know about the
			new functionality as well as maintain the integrity of existing
			dictionaries.
			5.6. Justifying the Allocation of Application-Id
			Application designers should avoid justifying the allocation of
			application IDs for every change that is made to an existing
			application. Proliferation of application ID can lead to confusion
			and an in-efficient use of the application ID namespaces.
			Application designers should always use Section 4 as a basis for
			justifying allocation of a new application ID.
			5.7. Use of Application-Id in a Message
			When designing new applications, designers should specify that the
			application ID carried in all session level messages must be the
			application ID of the application using those messages. This
			includes the session level messages defined in base protocol, i.e.,
			RAR/RAA, STR/STA, ASR/ASA and possibly ACR/ACA in the coupled
			accounting model, see Section 5.1. Existing specifications may not
			adhere to this rule for historical or other reasons. However, this
			scheme is followed to avoid possible routing problems for these
			messages.
			Additionally, application designers using the Vendor-Specific-
			Application-Id AVP should note that the Vendor-Id AVP will not be
			used in any way by the Diameter message delivery layer. Therefore
			its meaning and usage should be segregated only within the
			application.
			5.8. Application Specific Session Statemachine
			Section 8 of [1] provides session statemachines for authentication,
			authorization and accounting (AAA) services. When a new application
			is being defined that cannot clearly be categorized into any of these
			services it is recommended that the application itself defines its
			own session statemachine. The existing session statemachines defined
			by [1] is not intended for general use beyond AAA services therefore
			any new behavior would most likely not fit well. Support for server
			initiated request is a clear example where an application specific
			session statemachine would be needed; i.e. Rw interface for ITU-T
			push model.
			5.9. System Architecture and Deployment
	The following are some of the architecture considerations that		The following are some of the architecture considerations that
	applications designers should contemplate when defining new		applications designers should contemplate when defining new
	applications:		applications:
	o For general AAA applications, Diameter requires more message		o For general AAA applications, Diameter requires more message
	exchanges for the same set of services compared to RADIUS.		exchanges for the same set of services compared to RADIUS.
	Therefore, application designers should consider scalability		Therefore, application designers should consider scalability
	issues during the design process.		issues during the design process.
	skipping to change at page 16, line 32		skipping to change at page 13, line 6
	timer Tw, its use on application level is discouraged since Tw is		timer Tw, its use on application level is discouraged since Tw is
	a hop-by-hop timer and it would not be relevant for end-to-end		a hop-by-hop timer and it would not be relevant for end-to-end
	message delivery error detection. In such a case, it is		message delivery error detection. In such a case, it is
	recommended that applications should define their own set of		recommended that applications should define their own set of
	timers for such purpose.		timers for such purpose.
	o Applications should specify AVPs which could be used to further		o Applications should specify AVPs which could be used to further
	aid in duplication detection. In some cases, when extending an		aid in duplication detection. In some cases, when extending an
	application, existing AVPs can be reused to provide additional		application, existing AVPs can be reused to provide additional
	duplication detection indicators; i.e., combination of Session-Id		duplication detection indicators; i.e., combination of Session-Id
	and CC-Request-Number AVPs in the Diameter Credit Control		and CC-Request-Number AVPs in the Diameter Credit Control
	application [4]. In cases where the extensions needs to define		application [8]. In cases where the extensions needs to define
	new AVPs, it is recommended that the new AVPs be used only for		new AVPs, it is recommended that the new AVPs be used only for
	this purpose.		this purpose.
	7. IANA Considerations		6. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	8. Security Considerations		7. Security Considerations
	This document does provides guidelines and considerations for		This document does provides guidelines and considerations for
	extending Diameter and Diameter applications. It does not define nor		extending Diameter and Diameter applications. It does not define nor
	address security related protocols or schemes.		address security related protocols or schemes.
	9. Acknowledgments		8. Acknowledgments
	We greatly appreciate the insight provided by Diameter implementers		We greatly appreciate the insight provided by Diameter implementers
	who have highlighted the issues and concerns being addressed by this		who have highlighted the issues and concerns being addressed by this
	document.		document.
	10. References		9. References
	10.1. Normative References
	[1] Fajardo, V., "Diameter Base Protocol",
	draft-ietf-dime-rfc3588bis-04 (work in progress), June 2007.
	[2] Bournelle, J., "Diameter Mobile IPv6: Support for Home Agent to
	Diameter Server Interaction", draft-ietf-dime-mip6-split-03
	(work in progress), July 2007.
	[3] Zorn, G., "Diameter Quality of Service Application",		9.1. Normative References
	draft-ietf-dime-diameter-qos-00 (work in progress),
	February 2007.
	[4] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.		[1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
	Loughney, "Diameter Credit-Control Application", RFC 4006,		"Diameter Base Protocol", RFC 3588, September 2003.
	August 2005.
	[5] 3GPP, "IMS Cx and Dx interfaces : signalling flows and message		[2] 3GPP, "IMS Cx and Dx interfaces : signalling flows and message
	contents", 3GPP TS 29.228 Version 7.0.0 2006.		contents", 3GPP TS 29.228 Version 7.0.0 2006.
	[6] 3GPP, "IMS Cx and Dx interfaces based on the Diameter protocol;		[3] 3GPP, "IMS Cx and Dx interfaces based on the Diameter protocol;
	Protocol details", 3GPP TS 29.229 Version 7.0.0 2006.		Protocol details", 3GPP TS 29.229 Version 7.0.0 2006.
	[7] 3GPP, "IMS Sh interface : signalling flows and message		[4] 3GPP, "IMS Sh interface : signalling flows and message
	content", 3GPP TS 29.328 Version 6.8.0 2005.		content", 3GPP TS 29.328 Version 6.8.0 2005.
	[8] 3GPP, "IMS Sh interface based on the Diameter protocol;		[5] 3GPP, "IMS Sh interface based on the Diameter protocol;
	Protocol details", 3GPP TS 29.329 Version 6.6.0 2005.		Protocol details", 3GPP TS 29.329 Version 6.6.0 2005.
	10.2. Informative References		[6] Bournelle, J., "Diameter Mobile IPv6: HA <-> HAAA Support",
			draft-ietf-dime-mip6-split-02 (work in progress), May 2007.
			[7] Zorn, G., "Diameter Quality of Service Application",
			draft-ietf-dime-diameter-qos-00 (work in progress),
			February 2007.
			[8] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
			Loughney, "Diameter Credit-Control Application", RFC 4006,
			August 2005.
			9.2. Informative References
	[9] Calhoun, P., "Diameter Resource Management Extensions",		[9] Calhoun, P., "Diameter Resource Management Extensions",
	draft-calhoun-diameter-res-mgmt-08.txt (work in progress),		draft-calhoun-diameter-res-mgmt-08.txt (work in progress),
	March 2001.		March 2001.
	[10] Asveren, T., "Diameter Duplicate Detection Cons.",		[10] Asveren, T., "Diameter Duplicate Detection Cons.",
	draft-asveren-dime-dupcons-00 (work in progress), August 2006.		draft-asveren-dime-dupcons-00 (work in progress), August 2006.
	Authors' Addresses		Authors' Addresses
End of changes. 59 change blocks.
	464 lines changed or deleted		294 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/