|
Page 1 of 4 The DIAMETER basic protocol is designed to provide a framework for services requiring AAA support, at the access technology level.
The protocol is intended to be flexible enough to allow services to add building blocks (or extensions) to the base DIAMETER protocol to meet their requirements. Unlike other AAA protocols for access technologies - such as PPP dial-in, Mobile IP and others -, DIAMETER uses a peer to peer architecture rather than a more classic client/server scheme. DIAMETER is recognised as a peer to peer protocol since any node is free to initiate a request at any time. Messages initiated by a server towards a client are usually requests to abort a service to a specific user. DIAMETER is also meant to operate both with local and with roaming situations. Since DIAMETER is not a complete protocol by itself, but it needs application-specific extensions from the technology, or architecture, used to access the network, it is not possible to describe or compare the protocol’s details regarding security and other aspects. Thus, the following discussion will deal mainly with the elements that are provided by the basic common DIAMETER framework: message format, message transport, error reporting, accounting and security considerations. DIAMETER is still a draft from the Authentication Authorisation and Accounting IETF group. Protocol Overview DIAMETER peers communicate exchanging a number of messages in order to provide the following facilities :  | Delivery of Attribute Value Pairs (AVPes) |  | Capabilities Negotiation |  | Error Notification |  | Extensibility, through addition of new commands and AVPes |  | Basic services necessary for applications, such as handling of user sessions or accounting |
AVP is the most important object within the DIAMETER protocol; it is used to deliver all data. Certain AVPes are needed by DIAMETER itself to operate, while others deliver data associated with the applications exploiting DIAMETER. AVPes containing application specific information may be arbitrarily added to DIAMETER messages, as long as the required AVPes are present and the ones that are to be added are not explicitly forbidden by the protocol rules. AVPes needed by DIAMETER to support itself, in providing the required features, are used for :  | Transporting of user authentication information, for the purposes of enabling DIAMETER servers to authenticate users. |  | Transporting of service specific authorisation information, between client and servers, allowing the peers to decide whether a user's access request should be granted or not. |  | Exchanging resource usage information, which may be used for accounting purposes, capacity planning, etc. |  | Relaying, proxying and redirecting of DIAMETER messages through a server hierarchy. |  | Given these AVPes, DIAMETER is capable of providing the minimum requirements needed to implement a solid AAA architecture. |
|