IETF68 DIME WG Diameter Applications Design Guidelines Document (draft-fajardo-dime-app-design-guide-00.txt)

IETF68 DIME WG Overview Purpose –To aid Diameter application designers on how to extend Diameter –Describes some of the possible tradeoffs encountered when designing applications –Clarify the extensibility rules in RFC3588 The document is NOT: –Intended to replace or change existing extensibility rules –Intended to add new rules

IETF68 DIME WG Rules of Diameter Extensibility How to Extend Diameter – Allocation of Application Id –Creation of new mandatory AVP(s) –Creation of new command(s) When to Define New Applications –General Rule: Re-use AVPs and commands as much as possible –When adding new mandatory AVPs or AVP Values: Does this new AVP or AVP value significantly change the semantics of the application ? Can be difficult to determine what is a “significant” change Avoid use optional AVPs to add new semantics for existing applications Think about backward compatibility, use well known versioning schemes instead of adding new optional AVPs –When message roundtrip changes –When a new command is required

IETF68 DIME WG Design Considerations Common Tradeoffs –Use of a single applications can lead to monolithic architectures Can be similar to a RADIUS model –Complex management for distributed architectures Co-relation of application services, i.e. separation of authentication and authorization Increased traffic and implementation footprint Accounting support –Base protocol accounting, split model –ACR/ACA using app-id of the application, coupled model Generic extensions –Common to any applications, i.e. redundancy, auditing, congestion control etc. –Typically should not require a new application if: Peer-to-peer End-to-end but can be piggybacked to application traffic, i.e. Proxy-Info AVP Application Id used in base protocol session messages –Application level messages RAR/RAA, STR/STA and ASR/ASA should use the application id of the application Server initiated request and Diameter user sessions