1 / 4

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

The document provides guidelines for extending Diameter applications, including rules for creating new AVPs and commands. It discusses tradeoffs in application design, extensibility rules, and design considerations for efficient implementation.

raypeterson
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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 IETF68 DIME WG

More Related