< draft-fajardo-dime-app-design-guide-01.txt   draft-fajardo-dime-app-design-guide-02.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 Ulticom Inc. Intended status: Informational Sonus Network
Expires: October 7, 2007 H. Tschofenig Expires: October 20, 2007 H. Tschofenig
Siemens Networks GmbH & Co KG Siemens Networks GmbH & Co KG
G. McGregor G. McGregor
Alcatel-Lucent Alcatel-Lucent
J. Loughney J. Loughney
Nokia Research Center Nokia Research Center
April 5, 2007 April 18, 2007
Diameter Applications Design Guidelines Diameter Applications Design Guidelines
draft-fajardo-dime-app-design-guide-01.txt draft-fajardo-dime-app-design-guide-02.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 October 7, 2007. This Internet-Draft will expire on October 20, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Diameter Base protocol provides rules on how to extend Diameter The Diameter Base protocol provides rules on how to extend Diameter
and to create new Diameter applications. This is a companion and to create new Diameter applications. This is a companion
document to clarify these rules. This document does not intended to document to clarify these rules. This document does not intended to
skipping to change at page 3, line 38 skipping to change at page 3, line 38
Diameter Base 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 when defining new applications. o Discuss design choices when defining new applications.
o Present tradeoffs of design choices. o Present tradeoffs of design choices.
Note that it is not always possible to offer a complete and concise Note that it is not always possible to offer a complete and concise
answer to certain design choices. There is, however, the believe answer to certain design choices. There is, however, the belief that
that at a minimum, this document can be used as a guide to Diameter at a minimum, this document can be used as a guide to Diameter
extensibility. extensibility.
2. Terminology 2. Terminology
This document reuses the terminology used in [1]. This document reuses the terminology used in [1].
3. 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 for 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 a single instance of a of this document also treats a Diameter node as a single instance of
Diameter message delivery layer and one or more Diameter applications a Diameter message delivery layer and one or more Diameter
that uses it. applications using it.
4. Rules on Diameter Extensibility 4. Rules on Diameter Extensibility
The general theme of Diameter extensibility is to reuse AVPs, AVP The general theme of Diameter extensibility is to reuse AVPs, AVP
values, commands and applications as much as possible. However, values, commands and applications as much as possible. However,
there are also rules for extending Diameter as specified in Section 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 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 trying to define a new Diameter application. Defining a new Diameter
application can be done by: application can be done by:
Defining a completely new application Defining a completely new application
This case applies to applications which has requirements that This case applies to applications which have requirements that
cannot be filled by existing applications and would require cannot be filled by existing applications and would require
definition of new command(s), AVPs and AVP values. Typically, definition of new command(s), AVPs and AVP values. Typically,
there is little ambiguity about the decision to create these types there is little ambiguity about the decision to create these types
of applications. Some examples are the interfaces defined for the of applications. Some examples are the interfaces defined for the
IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([2] and [3]), Sh IP Multimedia Subsystem of 3GPP, i.e.; Cx/Dx ([2] and [3]), Sh
([4] and [5]) etc . Though some decisions maybe clear, designers ([4] and [5]) etc . Though some decisions may be clear, designers
should also consider certain aspects of the application itself. should also consider certain aspects of the application itself.
Some of these are described in Section 5. Applications design Some of these are described in Section 5. Applications design
should also follow the theme of Diameter extensibility which should also follow the theme of Diameter extensibility which
advocates reuse of AVPs and AVP values as much as possible even in advocates reuse of AVPs and AVP values as much as possible even in
newly defined commands. In certain cases where accounting will be newly defined commands. In certain cases where accounting will be
used, models described in Section 5.1 should be considered. used, the models described in Section 5.1 should be considered.
Extending an existing application Extending an existing application
In this case, the requirements of the new applications are not In this case, the requirements of the new applications are not
completely unique and there are existing applications that can be completely unique and there are existing application's that can be
reused to solve some or all of the application requirements. reused to solve some or all of the application requirements.
Therefore, there is a greater likelihood of ambiguity on how much Thus, there is a greater likelihood of ambiguity on how much of
of the existing application can be reused, to what extent and what the existing application can be reused, to what extent and what
are the implications for both the new and existing application. the implications for both the new and existing application.
Section 4.1 discusses some of the issues in this case. Section 4.1 discusses some of the issues in this case.
4.1. Rules on Extending Existing Applications 4.1. Rules on Extending Existing Applications
The Diameter base protocol provides a clear set of rules on when one The Diameter base protocol provides a clear set of rules on when one
should define a new Diameter application. In the context of this should define a new Diameter application. In the context of this
document, the rules are: document, the rules are:
Adding an AVP to a command ABNF of an existing application Adding an AVP to a command ABNF of an existing application
The rules are strict in the case where the AVP(s) to be added is The rules are strict in the case where the AVP(s) to be added is
mandatory to be understood and interpreted. This means that the mandatory to be understood and interpreted. This means that the
M-bit is set and the AVP(s) is required to exists in command ABNF. M-bit is set and the AVP(s) is required to exist in command ABNF.
Note that this mandatory AVP rules applies to AVP(s) that either Note that this mandatory AVP rule applies to AVP(s) that either
already exist in the same or in another application or the AVP(s) already exist in the same or in another application or the AVP(s)
are yet to be defined. In this case, the ambiguity arises when are yet to be defined. In the latter case, the ambiguity arises
trying to decide whether the AVP(s) should be mandatory or not. when trying to decide whether the AVP(s) should be mandatory or
There are several questions that application designers should not. There are several questions that application designers
contemplate when trying to decide: should contemplate when trying to decide:
* Does the AVP(s) change the state machine of the application ? * Does the AVP(s) change the state machine of the application ?
* Would the presence of the AVP(s) cause additional message * Would the presence of the AVP(s) cause additional message
round-trips; effectively changing the state machine of the round-trips; effectively changing the state machine of the
application ? application ?
* Will the AVP be used to fulfill new required functionality ? * Will the AVP be used to fulfill new required functionality ?
* 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 ?
* 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 ?
These questions are not comprehensive in anyway but in all cases These questions are not comprehensive in any way but in all cases
the semantics of the application must change to justify the use of the semantics of the application must change to justify the use of
mandatory AVPs. mandatory AVPs.
However, care should also be taken when opting for optional AVPs However, care should also be taken when opting for optional AVPs
instead of mandatory AVPs simply to avoid allocating new instead of mandatory AVPs simply to avoid allocating new
applications. Optional AVPs that falls into any of the applications. Optional AVPs that fall into any of the categorical
categorical questions above would have consequences. See questions above would have consequences. See Section 5.4 for
Section 5.4 for details. details.
Add a new AVP value to an to an existing AVP Add a new AVP value to an to an existing AVP
In this case, the rule applies to existing mandatory AVPs already In this case, the rule applies to existing mandatory AVPs already
present in a command ABNF where the semantics of the AVP changes. 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 This means that the meaning or usage of the AVP has changed and
significantly affects the behavior of the application. Although significantly affects the behavior of the application. Although
this case maybe less common or seem more subtle, the exact same this case may be less common or seem more subtle, the exact same
considerations given in the first scenario above applies here as considerations given in the first scenario above apply here as
well. well.
Add a command to an existing application Add a command to an existing application
In this case, the rule applies to defining a new command for an In this case, the rule applies to defining a new command for an
existing application or importing an existing command from another existing application or importing an existing command from another
application so as to inherit some or all of the functionality of application so as to inherit some or all of the functionality of
that application. In the first case, the decision is straight that application. In the first case, the decision is straight
forward since this is typically a result of adding new forward since this is typically a result of adding new
functionality that does not yet exist. The latter case would functionality that does not yet exist. The latter case would
result in a new application but it has a more subtle issue such as result in a new application but it has a more subtle issue such as
deciding whether importing of commands and functionality is really deciding whether importing of commands and functionality is really
better than simply using the existing application as is in better than simply using the existing application as it is in
conjunction with any new application. conjunction with any new application.
A typical example would be the Diameter MIPv6 split scenario (see A typical example would be the Diameter MIPv6 split scenario (see
[6]) in which several application models would have been possible [6]) in which several application models would have been possible
during the design phase; one model would reuse existing Diameter during the design phase; one model would reuse existing Diameter
EAP application combined with a new Diameter MIPv6 application to EAP application combined with a new Diameter MIPv6 application to
form a complete authentication and authorization scheme and form a complete authentication and authorization scheme and
another would be to reuse Diameter EAP like commands within the another would be to reuse Diameter EAP like commands within the
new Diameter MIPv6 application to accomplish the same result. In new Diameter MIPv6 application to accomplish the same result. In
this case, the latter model was chosen which would permit the this case, the latter model was chosen which would permit the
reuse of commands and/or AVPs from one application to another. reuse of commands and/or AVPs from one application to another.
Other applications such as Diameter QoS (see [7]) would likely Other applications such as Diameter QoS (see [7]) would likely
face similar decisions. face similar decisions.
In general, it is difficult to come to a hard and fast guideline In general, it is difficult to come to a hard and fast guideline
for this scenario so a case by case study of each application for this scenario so a case by case study of each application
requirements should be applied. Before importing a command, requirement should be applied. Before importing a command,
application designers should consider whether: application designers should consider whether:
* The existing application can be reused as is without * The existing application can be reused as is without
fundamental changes; i.e. an optional AVP is sufficient to fundamental changes; i.e. an optional AVP is sufficient to
indicate support for new optional functionality if any. There indicate support for new optional functionality if any. There
are pitfalls to this as well. See Section 5.4 are pitfalls to this as well. See Section 5.4
* Reuse of existing applications as is would result in a * Reuse of existing applications would result in a distributed
distributed environment which may not be conducive to certain environment which may not be conducive to certain requirements
requirements of the applications; i.e. security and or of the applications; i.e. security and or deployment
deployment difficulties - because of Diameter routing, messages difficulties - because of Diameter routing, messages for
for different applications providing service to the same user different applications providing service to the same user may
may end up in different servers would then need to be co- end up in different servers would then need to be co-related.
related. This could mean extra signaling between application This could mean extra signaling between application servers. A
servers. A typical example would be the initial proposal for typical example would be the initial proposal for Diameter
Diameter MIPv6 split scenario (see [6]) where authorization and MIPv6 split scenario (see [6]) where authorization and
authentication is separated. authentication is separated.
5. 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.
5.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 have prevented easy use the clarity in the base protocol document has prevented easy use the base
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
In this model, the accounting messages will use the Diameter base In this model, the accounting messages will use the Diameter base
accounting application ID (value of 3). The design implication accounting application ID (value of 3). The design implication
for this is that the accounting is treated as an independent for this is that the accounting is treated as an independent
application, especially during routing. This means that application, especially during routing. This means that
accounting commands emanating from an application maybe routed accounting commands emanating from an application may be routed
separately from the rest of the other application messages. This separately from the rest of the other application messages. This
also implies that the messages generally end up in a central also implies that the messages generally end up in a central
accounting server. A split accounting model is a good design accounting server. A split accounting model is a good design
choice when: choice when:
* The application itself will not define its own unique * The application itself will not define its own unique
accounting commands. accounting commands.
* The overall system architecture permits the use of centralized * The overall system architecture permits the use of centralized
accounting for one or more Diameter applications. accounting for one or more Diameter applications.
skipping to change at page 8, line 23 skipping to change at page 8, line 23
(application entity receiving the ACR message) to send the (application entity receiving the ACR message) to send the
accounting records carried by the accounting messages to the accounting records carried by the accounting messages to the
proper accounting server. The application server is also proper accounting server. The application server is also
responsible for formulating a proper response (ACA). A coupled responsible for formulating a proper response (ACA). A coupled
accounting model is a good design choice when: accounting model is a good design choice when:
* The system architecture or deployment will not provide an * The system architecture or deployment will not provide an
accounting server that supports Diameter. accounting server that supports Diameter.
* The system architecture or deployment requires that the * The system architecture or deployment requires that the
accounting for the specific application should be handled by accounting service for the specific application should be
the application itself. handled by the application itself.
* The accounting server is provisioned to use a different * The application server is provisioned to use a different
protocol to access the accounting server; i.e., via LDAP, XML protocol to access the accounting server; i.e., via LDAP, XML
etc. This includes attempting to supporting older accounting etc. This includes attempting to supporting older accounting
systems that are not Diameter aware. systems that are not Diameter aware.
In all most above, there will generally be no direct Diameter In all cases above, there will generally be no direct Diameter
access to the accounting server. access to the accounting server.
These models provide a basis for using accounting messages. These models provide a basis for using accounting messages.
Application designers may obviously deviate from these models Application designers may obviously deviate from these models
provided that the factors being addressed here have also been taken provided that the factors being addressed here have also been taken
into account. Though its not recommended, examples of other methods into account. Though it is not recommended, examples of other
would be defining a new set of command to carry application specific methods would be defining a new set of commands to carry application
accounting records. specific accounting records.
Additionally, application ID in the message header and Accounting- Additionally, the application ID in the message header and
Application-Id AVP are populated depending on the accounting model Accounting-Application-Id AVP are populated depending on the
used for a specific application, as described in [1]. Therefore, accounting model used for a specific application, as described in
application designers have to specify the accounting model used to [1]. Therefore, application designers have to specify the accounting
guarantee proper routing of accounting requests. model used to guarantee proper routing of accounting requests.
5.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 [8]), improvements in duplicate detection scheme (see [9]). (see [8]), improvements in duplicate detection scheme (see [9]).
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
probable scenarios in this document. However, some of the most probable scenarios in this document. However, some of the most
common considerations are as follows: common considerations are as follows:
o Backward compatibility: Dealing with existing applications that do o Backward compatibility: Dealing with existing applications that do
not understand the new extension. Designers also have to make not understand the new extension. Designers also have to make
sure that new extensions does not break expected message delivery sure that new extensions do not break expected message delivery
layer behavior. layer behavior.
o Forward compatibility: Making sure that the design will not o Forward compatibility: Making sure that the design will not
introduce undue restrictions for future applications. Future introduce undue restrictions for future applications. Future
applications attempting to support this feature should not have to applications attempting to support this feature should not have to
go through great lengths to implement any new extensions. go through great lengths to implement any new extensions.
o Tradeoffs in signaling: Designers may have to choose between the o Tradeoffs in signaling: Designers may have to choose between the
use of optional AVPs piggybacked into existing commands versus use of optional AVPs piggybacked onto existing commands versus
defining new commands and applications. Optional AVPs are simpler defining new commands and applications. Optional AVPs are simpler
to implement and may not need changes to existing applications; to implement and may not need changes to existing applications;
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.
5.3. Updating an existing Application 5.3. Updating an existing Application
An application that is being upgraded must follow the same rules in An application that is being upgraded must follow the same rules
Section 4. Even if the new version is fundamentally the same mentioned Section 4. Even if the new version is fundamentally the
application, allocation of a new application ID is possible if it same application, allocation of a new application ID is possible if
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 5.4 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.6. this approach is discussed in Section 5.6.
5.4. Use of optional AVPs 5.4. Use of optional AVPs
Problems arises when there is a tendency by applications designers to Problems arise when there is a tendency by applications designers to
keep adding optional AVPs to an existing command so they can keep adding optional AVPs to an existing command so they can
circumvent the extension rules in Section 4. Some of the pitfalls circumvent the extension rules in Section 4. Some of the pitfalls
that application designers should avoid is as follows: that application designers should avoid are:
o Use of optional AVPs with intersecting meaning; one AVP has o Use of optional AVPs with intersecting meaning; one AVP has
partially the same usage and/or meaning as another AVP. The partially the same usage and/or meaning as another AVP. The
presence of both can lead to confusion. presence of both can lead to confusion.
o Optional AVPs with dual purpose; i.e.; to carry applications data 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 as well as to indicate support for one or more features. This has
a tendency to introduce interpretation issues. a tendency to introduce interpretation issues.
o Use of optional AVPs with a minimum occurrence of one(1) in the o Use of optional AVPs with a minimum occurrence of one(1) in the
command ABNF. This is generally contradictory. Application command ABNF. This is generally contradictory. Application
designers should not use this scheme to circumvent definition of designers should not use this scheme to circumvent definition of
mandatory AVPs. mandatory AVPs.
All of these practices generally results in interoperability problems All of these practices generally result in interoperability problems
so they should be avoided as much as possible. so they should be avoided as much as possible.
5.5. Deleting AVPs from a Command ABNF 5.5. Deleting AVPs from a Command ABNF
Although this scenario is not as common, the deletion of AVPs from a Although this scenario is not as common, the deletion of AVPs from a
command ABNF is significant to when trying to extend an existing command ABNF is significant when trying to extend an existing
application. Deletion can be categorized between deletion of application. Deletion can be categorized between deletion of
mandatory and optional AVPs. mandatory and optional AVPs.
In the unlikely event that an application designer would require that In the unlikely event that an application designer would require that
mandatory AVPs must be deleted then it constitutes a fundamental mandatory AVPs must be deleted then it constitutes a fundamental
change to an existing application. Though not specified in [1], change to an existing application. Though not specified in [1],
deletion of mandatory would require the allocation of a new deletion of mandatory would require the allocation of a new
application since it dictates changes in the behavior and semantics application since it dictates changes in the behavior and semantics
of an application. of an application.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
o Application design should consider some form of redundancy. o Application design should consider some form of redundancy.
Session state information is the primary data necessary for Session state information is the primary data necessary for
backup/recovering endpoints to continue processing for an backup/recovering endpoints to continue processing for an
previously existing session. Carrying enough information in the previously existing session. Carrying enough information in the
messages to reconstruct session state facilitates redundant messages to reconstruct session state facilitates redundant
implementations and is highly recommended. implementations and is highly recommended.
o Application design should segregate message delivery layer o Application design should segregate message delivery layer
processing from application level processing. An example is the processing from application level processing. An example is the
use of timers to detect lack of a response for a previously sent use of timers to detect lack of a response for a previously sent
requests. Although Diameter base protocol defines a watchdog requests. Although the Diameter base protocol defines a watchdog
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 its use would not be relevant for end-to- a hop-by-hop timer and it would not be relevant for end-to-end
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 its own set of timers recommended that applications should define their own set of
for such purpose. timers for such purpose.
6. IANA Considerations 6. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
7. 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.
skipping to change at page 14, line 16 skipping to change at page 14, line 16
Victor Fajardo (editor) Victor Fajardo (editor)
Toshiba America Research Inc. Toshiba America Research Inc.
One Telcordia Drive One Telcordia Drive
Piscataway, NJ 08854 Piscataway, NJ 08854
USA USA
Email: vfajardo@tari.toshiba.com Email: vfajardo@tari.toshiba.com
Tolga Asveren Tolga Asveren
Ulticom Inc. Sonus Network
1020 Briggs Road 4400 Route 9 South
Mount Laurel, NJ, 08054 Freehold, NJ, 07728
USA USA
Email: asveren@ulticom.com Email: tasveren@sonusnet.com
Hannes Tschofenig Hannes Tschofenig
Siemens Networks GmbH & Co KG Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Phone: +49 89 636 40390 Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
 End of changes. 38 change blocks. 
75 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/