modified by Diameter agents of any kind, and the same value in the corresponding request is used in the answer. Attribute–Value Pairs (AVP) For simplicity, AVP Flag "V" bit Means Vendor Specific; "M" bit means Mandatory; "P" bit means Protected. The "V" bit, known as the Vendor-Specific bit, indicates whether the optional Vendor-ID field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space. The "M" bit, known as the Mandatory bit, indicates whether support of the AVP is required. If an AVP with the "M" bit set is received by a Diameter client, server, proxy, or translation agent and either the AVP or its value is unrecognized, the message must be rejected. Diameter Relay and redirect agents must not reject messages with unrecognized AVPs. The "P" bit indicates the need for encryption for end-to-end security. State machines The RFC 3588 defines a core state machine for maintaining connections between peers and processing messages. This is part of the basic protocol functionality and all stacks should support it and as such abstract from the connectivity related operations. Additionally, application specific state machines can be introduced either later or at a higher abstraction layer. The RFC 3588 defines an authorization and an accounting state machine. Message flows The communication between two diameter peers starts with the establishment of a transport connection (TCP or SCTP). The initiator then sends a Capabilities-Exchange-Request (CER) to the other peer, which responds with a Capabilities-Exchange-Answer (CEA). For RFC3588 compliant peers TLS (Transport Layer Security) may optionally be negotiated. For RFC6733 compliant peers TLS negotiation may optionally happen before the CER/CEA. The connection is then ready for exchanging application messages. If no messages have been exchanged for some time either side may send a Device-Watchdog-Request (DWR) and the other peer must respond with Device-Watchdog-Answer. Either side may terminate the communication by sending a Disconnect-Peer-Request (DPR) which the other peer must respond to with Disconnect-Peer-Answer. After that the transport connection can be disconnected. RFCs The Diameter protocol is currently defined in the following IETF RFCs: Obsolete RFCs are indicated with strikethrough text. See also List of authentication protocols Host Identity Protocol (HIP) References External links Introduction to Diameter - Get the next generation AAA protocol Cisco page outlining differences between RADIUS and DIAMETER Diameter: next generation’s AAA protocol Paper about Diameter by Håkan Ventura Reference page listing vendors of