RFC 6733
Diameter Base Protocol
Pages: 152
Proposed Standard
→ Errata
Obsoletes: 3588 5719
Updated by: 7075 8553
Proposed Standard
→ Errata
Obsoletes: 3588 5719
Updated by: 7075 8553
Part 2 of 5 – Pages 20 to 57
2. Protocol Overview
The base Diameter protocol concerns itself with establishing connections to peers, capabilities negotiation, how messages are sent and routed through peers, and how the connections are eventually torn down. The base protocol also defines certain rules that apply to all message exchanges between Diameter nodes. Communication between Diameter peers begins with one peer sending a message to another Diameter peer. The set of AVPs included in the message is determined by a particular Diameter application. One AVP that is included to reference a user's session is the Session-Id. The initial request for authentication and/or authorization of a user would include the Session-Id AVP. The Session-Id is then used in all subsequent messages to identify the user's session (see Section 8 for
more information). The communicating party may accept the request or reject it by returning an answer message with the Result-Code AVP set to indicate that an error occurred. The specific behavior of the Diameter server or client receiving a request depends on the Diameter application employed. Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination- Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular Diameter application. The base Diameter protocol may be used by itself for accounting applications. For authentication and authorization, it is always extended for a particular application. Diameter clients MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the client's service, e.g., Network Access Server Requirements (NASREQ) [RFC2881] and/or Mobile IPv4. A Diameter client MUST be referred to as "Diameter X Client" where X is the application that it supports and not a "Diameter Client". Diameter servers MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement the intended service, e.g., NASREQ and/or Mobile IPv4. A Diameter server MUST be referred to as "Diameter X Server" where X is the application that it supports, and not a "Diameter Server". Diameter relays and redirect agents are transparent to the Diameter applications, but they MUST support the Diameter base protocol, which includes accounting, and all Diameter applications. Diameter proxies MUST support the base protocol, which includes accounting. In addition, they MUST fully support each Diameter application that is needed to implement proxied services, e.g., NASREQ and/or Mobile IPv4. A Diameter proxy MUST be referred to as "Diameter X Proxy" where X is the application which it supports, and not a "Diameter Proxy".
2.1. Transport
The Diameter Transport profile is defined in [RFC3539]. The base Diameter protocol is run on port 3868 for both TCP [RFC0793] and SCTP [RFC4960]. For TLS [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347], a Diameter node that initiates a connection prior to any message exchanges MUST run on port 5658. It is assumed that TLS is run on top of TCP when it is used, and DTLS is run on top of SCTP when it is used. If the Diameter peer does not support receiving TLS/TCP and DTLS/SCTP connections on port 5658 (i.e., the peer complies only with RFC 3588), then the initiator MAY revert to using TCP or SCTP on port 3868. Note that this scheme is kept only for the purpose of backward compatibility and that there are inherent security vulnerabilities when the initial CER/CEA messages are sent unprotected (see Section 5.6). Diameter clients MUST support either TCP or SCTP; agents and servers SHOULD support both. A Diameter node MAY initiate connections from a source port other than the one that it declares it accepts incoming connections on, and it MUST always be prepared to receive connections on port 3868 for TCP or SCTP and port 5658 for TLS/TCP and DTLS/SCTP connections. When DNS-based peer discovery (Section 5.2) is used, the port numbers received from SRV records take precedence over the default ports (3868 and 5658). A given Diameter instance of the peer state machine MUST NOT use more than one transport connection to communicate with a given peer, unless multiple instances exist on the peer, in which, case a separate connection per process is allowed. When no transport connection exists with a peer, an attempt to connect SHOULD be made periodically. This behavior is handled via the Tc timer (see Section 12 for details), whose recommended value is 30 seconds. There are certain exceptions to this rule, such as when a peer has terminated the transport connection stating that it does not wish to communicate. When connecting to a peer and either zero or more transports are specified, TLS SHOULD be tried first, followed by DTLS, then by TCP, and finally by SCTP. See Section 5.2 for more information on peer discovery.
Diameter implementations SHOULD be able to interpret ICMP protocol port unreachable messages as explicit indications that the server is not reachable, subject to security policy on trusting such messages. Further guidance regarding the treatment of ICMP errors can be found in [RFC5927] and [RFC5461]. Diameter implementations SHOULD also be able to interpret a reset from the transport and timed-out connection attempts. If Diameter receives data from the lower layer that cannot be parsed or identified as a Diameter error made by the peer, the stream is compromised and cannot be recovered. The transport connection MUST be closed using a RESET call (send a TCP RST bit) or an SCTP ABORT message (graceful closure is compromised).2.1.1. SCTP Guidelines
Diameter messages SHOULD be mapped into SCTP streams in a way that avoids head-of-the-line (HOL) blocking. Among different ways of performing the mapping that fulfill this requirement it is RECOMMENDED that a Diameter node send every Diameter message (request or response) over stream zero with the unordered flag set. However, Diameter nodes MAY select and implement other design alternatives for avoiding HOL blocking such as using multiple streams with the unordered flag cleared (as originally instructed in RFC 3588). On the receiving side, a Diameter entity MUST be ready to receive Diameter messages over any stream, and it is free to return responses over a different stream. This way, both sides manage the available streams in the sending direction, independently of the streams chosen by the other side to send a particular Diameter message. These messages can be out-of-order and belong to different Diameter sessions. Out-of-order delivery has special concerns during a connection establishment and termination. When a connection is established, the responder side sends a CEA message and moves to R-Open state as specified in Section 5.6. If an application message is sent shortly after the CEA and delivered out-of-order, the initiator side, still in Wait-I-CEA state, will discard the application message and close the connection. In order to avoid this race condition, the receiver side SHOULD NOT use out-of-order delivery methods until the first message has been received from the initiator, proving that it has moved to I-Open state. To trigger such a message, the receiver side could send a DWR immediately after sending a CEA. Upon reception of the corresponding DWA, the receiver side should start using out-of- order delivery methods to counter the HOL blocking. Another race condition may occur when DPR and DPA messages are used. Both DPR and DPA are small in size; thus, they may be delivered to the peer faster than application messages when an out-of-order delivery mechanism is used. Therefore, it is possible that a DPR/DPA
exchange completes while application messages are still in transit, resulting in a loss of these messages. An implementation could mitigate this race condition, for example, using timers, and wait for a short period of time for pending application level messages to arrive before proceeding to disconnect the transport connection. Eventually, lost messages are handled by the retransmission mechanism described in Section 5.5.4. A Diameter agent SHOULD use dedicated payload protocol identifiers (PPIDs) for clear text and encrypted SCTP DATA chunks instead of only using the unspecified payload protocol identifier (value 0). For this purpose, two PPID values are allocated: the PPID value 46 is for Diameter messages in clear text SCTP DATA chunks, and the PPID value 47 is for Diameter messages in protected DTLS/SCTP DATA chunks.2.2. Securing Diameter Messages
Connections between Diameter peers SHOULD be protected by TLS/TCP and DTLS/SCTP. All Diameter base protocol implementations MUST support the use of TLS/TCP and DTLS/SCTP. If desired, alternative security mechanisms that are independent of Diameter, such as IPsec [RFC4301], can be deployed to secure connections between peers. The Diameter protocol MUST NOT be used without one of TLS, DTLS, or IPsec.2.3. Diameter Application Compliance
Application Ids are advertised during the capabilities exchange phase (see Section 5.3). Advertising support of an application implies that the sender supports the functionality specified in the respective Diameter application specification. Implementations MAY add arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) to a command defined in an application, but only if the command's CCF syntax specification allows for it. Please refer to Section 11.1.1 for details.2.4. Application Identifiers
Each Diameter application MUST have an IANA-assigned Application ID. The base protocol does not require an Application Id since its support is mandatory. During the capabilities exchange, Diameter nodes inform their peers of locally supported applications. Furthermore, all Diameter messages contain an Application Id, which is used in the message forwarding process.
The following Application Id values are defined:
Diameter common message 0
Diameter base accounting 3
Relay 0xffffffff
Relay and redirect agents MUST advertise the Relay Application ID,
while all other Diameter nodes MUST advertise locally supported
applications. The receiver of a Capabilities Exchange message
advertising relay service MUST assume that the sender supports all
current and future applications.
Diameter relay and proxy agents are responsible for finding an
upstream server that supports the application of a particular
message. If none can be found, an error message is returned with the
Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
2.5. Connections vs. Sessions
This section attempts to provide the reader with an understanding of
the difference between "connection" and "session", which are terms
used extensively throughout this document.
A connection refers to a transport-level connection between two peers
that is used to send and receive Diameter messages. A session is a
logical concept at the application layer that exists between the
Diameter client and the Diameter server; it is identified via the
Session-Id AVP.
+--------+ +-------+ +--------+
| Client | | Relay | | Server |
+--------+ +-------+ +--------+
<----------> <---------->
peer connection A peer connection B
<----------------------------->
User session x
Figure 1: Diameter Connections and Sessions
In the example provided in Figure 1, peer connection A is established
between the client and the relay. Peer connection B is established
between the relay and the server. User session X spans from the
client via the relay to the server. Each "user" of a service causes
an auth request to be sent, with a unique session identifier. Once
accepted by the server, both the client and the server are aware of
the session.
It is important to note that there is no relationship between a connection and a session, and that Diameter messages for multiple sessions are all multiplexed through a single connection. Also, note that Diameter messages pertaining to the session, both application- specific and those that are defined in this document such as ASR/ASA, RAR/RAA, and STR/STA, MUST carry the Application Id of the application. Diameter messages pertaining to peer connection establishment and maintenance such as CER/CEA, DWR/DWA, and DPR/DPA MUST carry an Application Id of zero (0).2.6. Peer Table
The Diameter peer table is used in message forwarding and is referenced by the routing table. A peer table entry contains the following fields: Host Identity Following the conventions described for the DiameterIdentity- derived AVP data format in Section 4.3.1, this field contains the contents of the Origin-Host (Section 6.3) AVP found in the CER or CEA message. StatusT This is the state of the peer entry, and it MUST match one of the values listed in Section 5.6. Static or Dynamic Specifies whether a peer entry was statically configured or dynamically discovered. Expiration Time Specifies the time at which dynamically discovered peer table entries are to be either refreshed or expired. If public key certificates are used for Diameter security (e.g., with TLS), this value MUST NOT be greater than the expiry times in the relevant certificates. TLS/TCP and DTLS/SCTP Enabled Specifies whether TLS/TCP and DTLS/SCTP is to be used when communicating with the peer. Additional security information, when needed (e.g., keys, certificates).
2.7. Routing Table
All Realm-Based routing lookups are performed against what is commonly known as the routing table (see Section 12). Each routing table entry contains the following fields: Realm Name This is the field that MUST be used as a primary key in the routing table lookups. Note that some implementations perform their lookups based on longest-match-from-the-right on the realm rather than requiring an exact match. Application Identifier An application is identified by an Application Id. A route entry can have a different destination based on the Application Id in the message header. This field MUST be used as a secondary key field in routing table lookups. Local Action The Local Action field is used to identify how a message should be treated. The following actions are supported: 1. LOCAL - Diameter messages that can be satisfied locally and do not need to be routed to another Diameter entity. 2. RELAY - All Diameter messages that fall within this category MUST be routed to a next-hop Diameter entity that is indicated by the identifier described below. Routing is done without modifying any non-routing AVPs. See Section 6.1.9 for relaying guidelines. 3. PROXY - All Diameter messages that fall within this category MUST be routed to a next Diameter entity that is indicated by the identifier described below. The local server MAY apply its local policies to the message by including new AVPs to the message prior to routing. See Section 6.1.9 for proxying guidelines. 4. REDIRECT - Diameter messages that fall within this category MUST have the identity of the home Diameter server(s) appended, and returned to the sender of the message. See Section 6.1.8 for redirection guidelines.
Server Identifier
The identity of one or more servers to which the message is to be
routed. This identity MUST also be present in the Host Identity
field of the peer table (Section 2.6). When the Local Action is
set to RELAY or PROXY, this field contains the identity of the
server(s) to which the message MUST be routed. When the Local
Action field is set to REDIRECT, this field contains the identity
of one or more servers to which the message MUST be redirected.
Static or Dynamic
Specifies whether a route entry was statically configured or
dynamically discovered.
Expiration Time
Specifies the time at which a dynamically discovered route table
entry expires. If public key certificates are used for Diameter
security (e.g., with TLS), this value MUST NOT be greater than the
expiry time in the relevant certificates.
It is important to note that Diameter agents MUST support at least
one of the LOCAL, RELAY, PROXY, or REDIRECT modes of operation.
Agents do not need to support all modes of operation in order to
conform with the protocol specification, but they MUST follow the
protocol compliance guidelines in Section 2. Relay agents and
proxies MUST NOT reorder AVPs.
The routing table MAY include a default entry that MUST be used for
any requests not matching any of the other entries. The routing
table MAY consist of only such an entry.
When a request is routed, the target server MUST have advertised the
Application Id (see Section 2.4) for the given message or have
advertised itself as a relay or proxy agent. Otherwise, an error is
returned with the Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
2.8. Role of Diameter Agents
In addition to clients and servers, the Diameter protocol introduces
relay, proxy, redirect, and translation agents, each of which is
defined in Section 1.2. Diameter agents are useful for several
reasons:
o They can distribute administration of systems to a configurable
grouping, including the maintenance of security associations.
o They can be used for concentration of requests from a number of
co-located or distributed NAS equipment sets to a set of like user
groups.
o They can do value-added processing to the requests or responses.
o They can be used for load balancing.
o A complex network will have multiple authentication sources, they
can sort requests and forward towards the correct target.
The Diameter protocol requires that agents maintain transaction
state, which is used for failover purposes. Transaction state
implies that upon forwarding a request, its Hop-by-Hop Identifier is
saved; the field is replaced with a locally unique identifier, which
is restored to its original value when the corresponding answer is
received. The request's state is released upon receipt of the
answer. A stateless agent is one that only maintains transaction
state.
The Proxy-Info AVP allows stateless agents to add local state to a
Diameter request, with the guarantee that the same state will be
present in the answer. However, the protocol's failover procedures
require that agents maintain a copy of pending requests.
A stateful agent is one that maintains session state information by
keeping track of all authorized active sessions. Each authorized
session is bound to a particular service, and its state is considered
active until either the agent is notified otherwise or the session
expires. Each authorized session has an expiration, which is
communicated by Diameter servers via the Session-Timeout AVP.
Maintaining session state may be useful in certain applications, such
as:
o Protocol translation (e.g., RADIUS <-> Diameter)
o Limiting resources authorized to a particular user
o Per-user or per-transaction auditing
A Diameter agent MAY act in a stateful manner for some requests and
be stateless for others. A Diameter implementation MAY act as one
type of agent for some requests and as another type of agent for
others.
2.8.1. Relay Agents
Relay agents are Diameter agents that accept requests and route messages to other Diameter nodes based on information found in the messages (e.g., the value of the Destination-Realm AVP Section 6.6). This routing decision is performed using a list of supported realms and known peers. This is known as the routing table, as is defined further in Section 2.7. Relays may, for example, be used to aggregate requests from multiple Network Access Servers (NASes) within a common geographical area (Point of Presence, POP). The use of relays is advantageous since it eliminates the need for NASes to be configured with the necessary security information they would otherwise require to communicate with Diameter servers in other realms. Likewise, this reduces the configuration load on Diameter servers that would otherwise be necessary when NASes are added, changed, or deleted. Relays modify Diameter messages by inserting and removing routing information, but they do not modify any other portion of a message. Relays SHOULD NOT maintain session state but MUST maintain transaction state. +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 2. Request | | | NAS | | DRL | | HMS | | | 4. Answer | | 3. Answer | | +------+ <--------- +------+ <--------- +------+ example.net example.net example.com Figure 2: Relaying of Diameter messages The example provided in Figure 2 depicts a request issued from a NAS, which is an access device, for the user bob@example.com. Prior to issuing the request, the NAS performs a Diameter route lookup, using "example.com" as the key, and determines that the message is to be relayed to a DRL, which is a Diameter relay. The DRL performs the same route lookup as the NAS, and relays the message to the HMS, which is example.com's home server. The HMS identifies that the request can be locally supported (via the realm), processes the authentication and/or authorization request, and replies with an answer, which is routed back to the NAS using saved transaction state. Since relays do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore, they MUST advertise the Relay Application Id.
2.8.2. Proxy Agents
Similar to relays, proxy agents route Diameter messages using the Diameter routing table. However, they differ since they modify messages to implement policy enforcement. This requires that proxies maintain the state of their downstream peers (e.g., access devices) to enforce resource usage, provide admission control, and provide provisioning. Proxies may, for example, be used in call control centers or access ISPs that provide outsourced connections; they can monitor the number and type of ports in use and make allocation and admission decisions according to their configuration. Since enforcing policies requires an understanding of the service being provided, proxies MUST only advertise the Diameter applications they support.2.8.3. Redirect Agents
Redirect agents are useful in scenarios where the Diameter routing configuration needs to be centralized. An example is a redirect agent that provides services to all members of a consortium, but does not wish to be burdened with relaying all messages between realms. This scenario is advantageous since it does not require that the consortium provide routing updates to its members when changes are made to a member's infrastructure. Since redirect agents do not relay messages, and only return an answer with the information necessary for Diameter agents to communicate directly, they do not modify messages. Since redirect agents do not receive answer messages, they cannot maintain session state. The example provided in Figure 3 depicts a request issued from the access device, NAS, for the user bob@example.com. The message is forwarded by the NAS to its relay, DRL, which does not have a routing entry in its Diameter routing table for example.com. The DRL has a default route configured to DRD, which is a redirect agent that returns a redirect notification to DRL, as well as the HMS' contact information. Upon receipt of the redirect notification, the DRL establishes a transport connection with the HMS, if one doesn't already exist, and forwards the request to it.
+------+ | | | DRD | | | +------+ ^ | 2. Request | | 3. Redirection | | Notification | v +------+ ---------> +------+ ---------> +------+ | | 1. Request | | 4. Request | | | NAS | | DRL | | HMS | | | 6. Answer | | 5. Answer | | +------+ <--------- +------+ <--------- +------+ example.net example.net example.com Figure 3: Redirecting a Diameter Message Since redirect agents do not perform any application-level processing, they provide relaying services for all Diameter applications; therefore, they MUST advertise the Relay Application ID.2.8.4. Translation Agents
A translation agent is a device that provides translation between two protocols (e.g., RADIUS<->Diameter, TACACS+<->Diameter). Translation agents are likely to be used as aggregation servers to communicate with a Diameter infrastructure, while allowing for the embedded systems to be migrated at a slower pace. Given that the Diameter protocol introduces the concept of long-lived authorized sessions, translation agents MUST be session stateful and MUST maintain transaction state. Translation of messages can only occur if the agent recognizes the application of a particular request; therefore, translation agents MUST only advertise their locally supported applications. +------+ ---------> +------+ ---------> +------+ | | RADIUS Request | | Diameter Request | | | NAS | | TLA | | HMS | | | RADIUS Answer | | Diameter Answer | | +------+ <--------- +------+ <--------- +------+ example.net example.net example.com Figure 4: Translation of RADIUS to Diameter
2.9. Diameter Path Authorization
As noted in Section 2.2, Diameter provides transmission-level security for each connection using TLS/TCP and DTLS/SCTP. Therefore, each connection can be authenticated and can be replay and integrity protected. In addition to authenticating each connection, the entire session MUST also be authorized. Before initiating a connection, a Diameter peer MUST check that its peers are authorized to act in their roles. For example, a Diameter peer may be authentic, but that does not mean that it is authorized to act as a Diameter server advertising a set of Diameter applications. Prior to bringing up a connection, authorization checks are performed at each connection along the path. Diameter capabilities negotiation (CER/CEA) also MUST be carried out, in order to determine what Diameter applications are supported by each peer. Diameter sessions MUST be routed only through authorized nodes that have advertised support for the Diameter application required by the session. As noted in Section 6.1.9, a relay or proxy agent MUST append a Route-Record AVP to all requests forwarded. The AVP contains the identity of the peer from which the request was received. The home Diameter server, prior to authorizing a session, MUST check the Route-Record AVPs to make sure that the route traversed by the request is acceptable. For example, administrators within the home realm may not wish to honor requests that have been routed through an untrusted realm. By authorizing a request, the home Diameter server is implicitly indicating its willingness to engage in the business transaction as specified by any contractual relationship between the server and the previous hop. A DIAMETER_AUTHORIZATION_REJECTED error message (see Section 7.1.5) is sent if the route traversed by the request is unacceptable. A home realm may also wish to check that each accounting request message corresponds to a Diameter response authorizing the session. Accounting requests without corresponding authorization responses SHOULD be subjected to further scrutiny, as should accounting requests indicating a difference between the requested and provided service. Forwarding of an authorization response is considered evidence of a willingness to take on financial risk relative to the session. A local realm may wish to limit this exposure, for example, by establishing credit limits for intermediate realms and refusing to accept responses that would violate those limits. By issuing an
accounting request corresponding to the authorization response, the local realm implicitly indicates its agreement to provide the service indicated in the authorization response. If the service cannot be provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error message MUST be sent within the accounting request; a Diameter client receiving an authorization response for a service that it cannot perform MUST NOT substitute an alternate service and then send accounting requests for the alternate service instead.3. Diameter Header
A summary of the Diameter header format is shown below. The fields are transmitted in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Flags | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Version This Version field MUST be set to 1 to indicate Diameter Version 1. Message Length The Message Length field is three octets and indicates the length of the Diameter message including the header fields and the padded AVPs. Thus, the Message Length field is always a multiple of 4. Command Flags The Command Flags field is eight bits. The following bits are assigned:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|R P E T r r r r|
+-+-+-+-+-+-+-+-+
R(equest)
If set, the message is a request. If cleared, the message is
an answer.
P(roxiable)
If set, the message MAY be proxied, relayed, or redirected. If
cleared, the message MUST be locally processed.
E(rror)
If set, the message contains a protocol error, and the message
will not conform to the CCF described for this command.
Messages with the 'E' bit set are commonly referred to as error
messages. This bit MUST NOT be set in request messages (see
Section 7.2).
T(Potentially retransmitted message)
This flag is set after a link failover procedure, to aid the
removal of duplicate requests. It is set when resending
requests not yet acknowledged, as an indication of a possible
duplicate due to a link failure. This bit MUST be cleared when
sending a request for the first time; otherwise, the sender
MUST set this flag. Diameter agents only need to be concerned
about the number of requests they send based on a single
received request; retransmissions by other entities need not be
tracked. Diameter agents that receive a request with the T
flag set, MUST keep the T flag set in the forwarded request.
This flag MUST NOT be set if an error answer message (e.g., a
protocol error) has been received for the earlier message. It
can be set only in cases where no answer has been received from
the server for a request, and the request has been sent again.
This flag MUST NOT be set in answer messages.
r(eserved)
These flag bits are reserved for future use; they MUST be set
to zero and ignored by the receiver.
Command Code
The Command Code field is three octets and is used in order to
communicate the command associated with the message. The 24-bit
address space is managed by IANA (see Section 3.1). Command Code
values 16,777,214 and 16,777,215 (hexadecimal values FFFFFE-
FFFFFF) are reserved for experimental use (see Section 11.2).
Application-ID
Application-ID is four octets and is used to identify for which
application the message is applicable. The application can be an
authentication application, an accounting application, or a
vendor-specific application.
The value of the Application-ID field in the header MUST be the
same as any relevant Application-Id AVPs contained in the message.
Hop-by-Hop Identifier
The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
network byte order) that aids in matching requests and replies.
The sender MUST ensure that the Hop-by-Hop Identifier in a request
is unique on a given connection at any given time, and it MAY
attempt to ensure that the number is unique across reboots. The
sender of an answer message MUST ensure that the Hop-by-Hop
Identifier field contains the same value that was found in the
corresponding request. The Hop-by-Hop Identifier is normally a
monotonically increasing number, whose start value was randomly
generated. An answer message that is received with an unknown
Hop-by-Hop Identifier MUST be discarded.
End-to-End Identifier
The End-to-End Identifier is an unsigned 32-bit integer field (in
network byte order) that is used to detect duplicate messages.
Upon reboot, implementations MAY set the high order 12 bits to
contain the low order 12 bits of current time, and the low order
20 bits to a random value. Senders of request messages MUST
insert a unique identifier on each message. The identifier MUST
remain locally unique for a period of at least 4 minutes, even
across reboots. The originator of an answer message MUST ensure
that the End-to-End Identifier field contains the same value that
was found in the corresponding request. The End-to-End Identifier
MUST NOT be modified by Diameter agents of any kind. The
combination of the Origin-Host AVP (Section 6.3) and this field is
used to detect duplicates. Duplicate requests SHOULD cause the
same answer to be transmitted (modulo the Hop-by-Hop Identifier
field and any routing AVPs that may be present), and they MUST NOT
affect any state that was set when the original request was
processed. Duplicate answer messages that are to be locally
consumed (see Section 6.2) SHOULD be silently discarded.
AVPs
AVPs are a method of encapsulating information relevant to the
Diameter message. See Section 4 for more information on AVPs.
3.1. Command Codes
Each command Request/Answer pair is assigned a Command Code, and the
sub-type (i.e., request or answer) is identified via the 'R' bit in
the Command Flags field of the Diameter header.
Every Diameter message MUST contain a Command Code in its header's
Command Code field, which is used to determine the action that is to
be taken for a particular message. The following Command Codes are
defined in the Diameter base protocol:
Section
Command Name Abbrev. Code Reference
--------------------------------------------------------
Abort-Session-Request ASR 274 8.5.1
Abort-Session-Answer ASA 274 8.5.2
Accounting-Request ACR 271 9.7.1
Accounting-Answer ACA 271 9.7.2
Capabilities-Exchange- CER 257 5.3.1
Request
Capabilities-Exchange- CEA 257 5.3.2
Answer
Device-Watchdog-Request DWR 280 5.5.1
Device-Watchdog-Answer DWA 280 5.5.2
Disconnect-Peer-Request DPR 282 5.4.1
Disconnect-Peer-Answer DPA 282 5.4.2
Re-Auth-Request RAR 258 8.3.1
Re-Auth-Answer RAA 258 8.3.2
Session-Termination- STR 275 8.4.1
Request
Session-Termination- STA 275 8.4.2
Answer
3.2. Command Code Format Specification
Every Command Code defined MUST include a corresponding Command Code Format (CCF) specification, which is used to define the AVPs that MUST or MAY be present when sending the message. The following ABNF specifies the CCF used in the definition: command-def = "<" command-name ">" "::=" diameter-message command-name = diameter-name diameter-name = ALPHA *(ALPHA / DIGIT / "-") diameter-message = header *fixed *required *optional header = "<Diameter-Header:" command-id [r-bit] [p-bit] [e-bit] [application-id]">" application-id = 1*DIGIT command-id = 1*DIGIT ; The Command Code assigned to the command. r-bit = ", REQ" ; If present, the 'R' bit in the Command ; Flags is set, indicating that the message ; is a request as opposed to an answer. p-bit = ", PXY" ; If present, the 'P' bit in the Command ; Flags is set, indicating that the message ; is proxiable. e-bit = ", ERR" ; If present, the 'E' bit in the Command ; Flags is set, indicating that the answer ; message contains a Result-Code AVP in ; the "protocol error" class. fixed = [qual] "<" avp-spec ">" ; Defines the fixed position of an AVP. required = [qual] "{" avp-spec "}" ; The AVP MUST be present and can appear ; anywhere in the message.
optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name that is included
; in a fixed or required rule. The AVP can
; appear anywhere in the message.
;
; NOTE: "[" and "]" have a slightly different
; meaning than in ABNF. These braces
; cannot be used to express optional fixed rules
; (such as an optional ICV at the end). To do
; this, the convention is '0*1fixed'.
qual = [min] "*" [max]
; See ABNF conventions, RFC 5234, Section 4.
; The absence of any qualifier depends on
; whether it precedes a fixed, required, or
; optional rule. If a fixed or required rule has
; no qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be
; present. If an optional rule has a qualifier,
; then the value of min MUST be 0 if present.
min = 1*DIGIT
; The minimum number of times the element may
; be present. If absent, the default value is 0
; for fixed and optional rules and 1 for
; required rules. The value MUST be at least 1
; for required rules.
max = 1*DIGIT
; The maximum number of times the element may
; be present. If absent, the default value is
; infinity. A value of 0 implies the AVP MUST
; NOT be present.
avp-spec = diameter-name
; The avp-spec has to be an AVP Name, defined
; in the base or extended Diameter
; specifications.
avp-name = avp-spec / "AVP"
; The string "AVP" stands for *any* arbitrary AVP
; Name, not otherwise listed in that Command Code
; definition. The inclusion of this string
; is recommended for all CCFs to allow for
; extensibility.
The following is a definition of a fictitious Command Code:
Example-Request ::= < Diameter Header: 9999999, REQ, PXY >
{ User-Name }
1* { Origin-Host }
* [ AVP ]
3.3. Diameter Command Naming Conventions
Diameter command names typically includes one or more English words
followed by the verb "Request" or "Answer". Each English word is
delimited by a hyphen. A three-letter acronym for both the request
and answer is also normally provided.
An example is a message set used to terminate a session. The command
name is Session-Terminate-Request and Session-Terminate-Answer, while
the acronyms are STR and STA, respectively.
Both the request and the answer for a given command share the same
Command Code. The request is identified by the R(equest) bit in the
Diameter header set to one (1), to ask that a particular action be
performed, such as authorizing a user or terminating a session. Once
the receiver has completed the request, it issues the corresponding
answer, which includes a result code that communicates one of the
following:
o The request was successful
o The request failed
o An additional request has to be sent to provide information the
peer requires prior to returning a successful or failed answer.
o The receiver could not process the request, but provides
information about a Diameter peer that is able to satisfy the
request, known as redirect.
Additional information, encoded within AVPs, may also be included in
answer messages.
4. Diameter AVPs
Diameter AVPs carry specific authentication, accounting,
authorization, and routing information as well as configuration
details for the request and reply.
Each AVP of type OctetString MUST be padded to align on a 32-bit boundary, while other AVP types align naturally. A number of zero- valued bytes are added to the end of the AVP Data field until a word boundary is reached. The length of the padding is not reflected in the AVP Length field.4.1. AVP Header
The fields in the AVP header MUST be sent in network byte order. The format of the header is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Code The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for reuse of RADIUS attributes, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA (see Section 11.1.1). AVP Flags The AVP Flags field informs the receiver how each attribute must be handled. New Diameter applications SHOULD NOT define additional AVP Flag bits. However, note that new Diameter applications MAY define additional bits within the AVP header, and an unrecognized bit SHOULD be considered an error. The sender of the AVP MUST set 'R' (reserved) bits to 0 and the receiver SHOULD ignore all 'R' (reserved) bits. The 'P' bit has been reserved for future usage of end-to-end security. At the time of writing, there are no end-to-end security mechanisms specified; therefore, the 'P' bit SHOULD be set to 0. The 'M' bit, known as the Mandatory bit, indicates whether the receiver of the AVP MUST parse and understand the semantics of the AVP including its content. The receiving entity MUST return an appropriate error message if it receives an AVP that has the M-bit
set but does not understand it. An exception applies when the AVP
is embedded within a Grouped AVP. See Section 4.4 for details.
Diameter relay and redirect agents MUST NOT reject messages with
unrecognized AVPs.
The 'M' bit MUST be set according to the rules defined in the
application specification that introduces or reuses this AVP.
Within a given application, the M-bit setting for an AVP is
defined either for all command types or for each command type.
AVPs with the 'M' bit cleared are informational only; a receiver
that receives a message with such an AVP that is not supported, or
whose value is not supported, MAY simply ignore the AVP.
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.
AVP Length
The AVP Length field is three octets, and indicates the number of
octets in this AVP including the AVP Code field, AVP Length field,
AVP Flags field, Vendor-ID field (if present), and the AVP Data
field. If a message is received with an invalid attribute length,
the message MUST be rejected.
4.1.1. Optional Header Elements
The AVP header contains one optional field. This field is only
present if the respective bit-flag is enabled.
Vendor-ID
The Vendor-ID field is present if the 'V' bit is set in the AVP
Flags field. The optional four-octet Vendor-ID field contains the
IANA-assigned "SMI Network Management Private Enterprise Codes"
[ENTERPRISE] value, encoded in network byte order. Any vendors or
standardization organizations that are also treated like vendors
in the IANA-managed "SMI Network Management Private Enterprise
Codes" space wishing to implement a vendor-specific Diameter AVP
MUST use their own Vendor-ID along with their privately managed
AVP address space, guaranteeing that they will not collide with
any other vendor's vendor-specific AVP(s) or with future IETF
AVPs.
A Vendor-ID value of zero (0) corresponds to the IETF-adopted AVP
values, as managed by IANA. Since the absence of the Vendor-ID
field implies that the AVP in question is not vendor specific,
implementations MUST NOT use the value of zero (0) for the
Vendor-ID field.
4.2. Basic AVP Data Formats
The Data field is zero or more octets and contains information
specific to the Attribute. The format and length of the Data field
is determined by the AVP Code and AVP Length fields. The format of
the Data field MUST be one of the following base data types or a data
type derived from the base data types. In the event that a new Basic
AVP Data Format is needed, a new version of this RFC MUST be created.
OctetString
The data contains arbitrary data of variable length. Unless
otherwise noted, the AVP Length field MUST be set to at least 8
(12 if the 'V' bit is enabled). AVP values of this type that are
not a multiple of 4 octets in length are followed by the necessary
padding so that the next AVP (if any) will start on a 32-bit
boundary.
Integer32
32-bit signed value, in network byte order. The AVP Length field
MUST be set to 12 (16 if the 'V' bit is enabled).
Integer64
64-bit signed value, in network byte order. The AVP Length field
MUST be set to 16 (20 if the 'V' bit is enabled).
Unsigned32
32-bit unsigned value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit is enabled).
Unsigned64
64-bit unsigned value, in network byte order. The AVP Length
field MUST be set to 16 (20 if the 'V' bit is enabled).
Float32
This represents floating point values of single precision as
described by [FLOATPOINT]. The 32-bit value is transmitted in
network byte order. The AVP Length field MUST be set to 12 (16 if
the 'V' bit is enabled).
Float64
This represents floating point values of double precision as
described by [FLOATPOINT]. The 64-bit value is transmitted in
network byte order. The AVP Length field MUST be set to 16 (20 if
the 'V' bit is enabled).
Grouped
The Data field is specified as a sequence of AVPs. These AVPs are
concatenated -- including their headers and padding -- in the
order in which they are specified and the result encapsulated in
the Data field. The AVP Length field is set to 8 (12 if the 'V'
bit is enabled) plus the total length of all included AVPs,
including their headers and padding. Thus, the AVP Length field
of an AVP of type Grouped is always a multiple of 4.
4.3. Derived AVP Data Formats
In addition to using the Basic AVP Data Formats, applications may
define data formats derived from the Basic AVP Data Formats. An
application that defines new Derived AVP Data Formats MUST include
them in a section titled "Derived AVP Data Formats", using the same
format as the definitions below. Each new definition MUST be either
defined or listed with a reference to the RFC that defines the
format.
4.3.1. Common Derived AVP Data Formats
The following are commonly used Derived AVP Data Formats.
Address
The Address format is derived from the OctetString Basic AVP
Format. It is a discriminated union representing, for example, a
32-bit (IPv4) [RFC0791] or 128-bit (IPv6) [RFC4291] address, most
significant octet first. The first two octets of the Address AVP
represent the AddressType, which contains an Address Family,
defined in [IANAADFAM]. The AddressType is used to discriminate
the content and format of the remaining octets.
Time
The Time format is derived from the OctetString Basic AVP Format.
The string MUST contain four octets, in the same format as the
first four bytes are in the NTP timestamp format. The NTP
timestamp format is defined in Section 3 of [RFC5905].
This represents the number of seconds since 0h on 1 January 1900
with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036, the time value will overflow.
Simple Network Time Protocol (SNTP) [RFC5905] describes a
procedure to extend the time to 2104. This procedure MUST be
supported by all Diameter nodes.
UTF8String
The UTF8String format is derived from the OctetString Basic AVP
Format. This is a human-readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString using
the UTF-8 transformation format [RFC3629].
Since additional code points are added by amendments to the 10646
standard from time to time, implementations MUST be prepared to
encounter any code point from 0x00000001 to 0x7fffffff. Byte
sequences that do not correspond to the valid encoding of a code
point into UTF-8 charset or are outside this range are prohibited.
The use of control codes SHOULD be avoided. When it is necessary
to represent a new line, the control code sequence CR LF SHOULD be
used.
The use of leading or trailing white space SHOULD be avoided.
For code points not directly supported by user interface hardware
or software, an alternative means of entry and display, such as
hexadecimal, MAY be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 charset is
identical to the US-ASCII charset.
UTF-8 may require multiple bytes to represent a single character /
code point; thus, the length of a UTF8String in octets may be
different from the number of characters encoded.
Note that the AVP Length field of an UTF8String is measured in
octets not characters.
DiameterIdentity
The DiameterIdentity format is derived from the OctetString Basic
AVP Format.
DiameterIdentity = FQDN/Realm
The DiameterIdentity value is used to uniquely identify either:
* A Diameter node for purposes of duplicate connection and
routing loop detection.
* A Realm to determine whether messages can be satisfied locally
or whether they must be routed or redirected.
When a DiameterIdentity value is used to identify a Diameter node,
the contents of the string MUST be the Fully Qualified Domain Name
(FQDN) of the Diameter node. If multiple Diameter nodes run on
the same host, each Diameter node MUST be assigned a unique
DiameterIdentity. If a Diameter node can be identified by several
FQDNs, a single FQDN should be picked at startup and used as the
only DiameterIdentity for that node, whatever the connection on
which it is sent. In this document, note that DiameterIdentity is
in ASCII form in order to be compatible with existing DNS
infrastructure. See Appendix D for interactions between the
Diameter protocol and Internationalized Domain Names (IDNs).
DiameterURI
The DiameterURI MUST follow the Uniform Resource Identifiers (RFC
3986) syntax [RFC3986] rules specified below:
"aaa://" FQDN [ port ] [ transport ] [ protocol ]
; No transport security
"aaas://" FQDN [ port ] [ transport ] [ protocol ]
; Transport security used
FQDN = < Fully Qualified Domain Name >
port = ":" 1*DIGIT
; One of the ports used to listen for
; incoming connections.
; If absent, the default Diameter port
; (3868) is assumed if no transport
; security is used and port 5658 when
; transport security (TLS/TCP and DTLS/SCTP)
; is used.
transport = ";transport=" transport-protocol
; One of the transports used to listen
; for incoming connections. If absent,
; the default protocol is assumed to be TCP.
; UDP MUST NOT be used when the aaa-protocol
; field is set to diameter.
transport-protocol = ( "tcp" / "sctp" / "udp" )
protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol
; is Diameter.
aaa-protocol = ( "diameter" / "radius" / "tacacs+" )
The following are examples of valid Diameter host identities:
aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius
Enumerated
The Enumerated format is derived from the Integer32 Basic AVP
Format. The definition contains a list of valid values and their
interpretation and is described in the Diameter application
introducing the AVP.
IPFilterRule
The IPFilterRule format is derived from the OctetString Basic AVP
Format and uses the ASCII charset. The rule syntax is a modified
subset of ipfw(8) from FreeBSD. Packets may be filtered based on
the following information that is associated with it:
Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types
Rules for the appropriate direction are evaluated in order, with the
first matched rule terminating the evaluation. Each packet is
evaluated once. If no rule matches, the packet is dropped if the
last rule evaluated was a permit, and passed if the last rule was a
deny.
IPFilterRule filters MUST follow the format:
action dir proto from src to dst [options]
action permit - Allow packets that match the rule.
deny - Drop packets that match the rule.
dir "in" is from the terminal, "out" is to the
terminal.
proto An IP protocol specified by number. The "ip"
keyword means any protocol will match.
src and dst <address/mask> [ports]
The <address/mask> may be specified as:
ipno An IPv4 or IPv6 number in dotted-
quad or canonical IPv6 form. Only
this exact IP number will match the
rule.
ipno/bits An IP number as above with a mask
width of the form 192.0.2.10/24. In
this case, all IP numbers from
192.0.2.0 to 192.0.2.255 will match.
The bit width MUST be valid for the
IP version, and the IP number MUST
NOT have bits set beyond the mask.
For a match to occur, the same IP
version must be present in the
packet that was used in describing
the IP address. To test for a
particular IP version, the bits part
can be set to zero. The keyword
"any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned"
is the address or set of addresses
assigned to the terminal. For IPv4,
a typical first rule is often "deny
in ip! assigned".
The sense of the match can be inverted by
preceding an address with the not modifier (!),
causing all other addresses to be matched
instead. This does not affect the selection of
port numbers.
With the TCP, UDP, and SCTP protocols, optional
ports may be specified as:
{port/port-port}[,ports[,...]]
The '-' notation specifies a range of ports
(including boundaries).
Fragmented packets that have a non-zero offset
(i.e., not the first fragment) will never match
a rule that has one or more port
specifications. See the frag option for
details on matching fragmented packets.
options:
frag Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or
TCP/UDP port specifications.
ipoptions spec
Match if the IP header contains the comma-separated
list of options specified in spec. The
supported IP options are:
ssrr (strict source route), lsrr (loose source
route), rr (record packet route), and ts
(timestamp). The absence of a particular option
may be denoted with a '!'.
tcpoptions spec
Match if the TCP header contains the comma-separated
list of options specified in spec. The
supported TCP options are:
mss (maximum segment size), window (tcp window
advertisement), sack (selective ack), ts (rfc1323
timestamp), and cc (rfc1644 t/tcp connection
count). The absence of a particular option may
be denoted with a '!'.
established
TCP packets only. Match packets that have the RST
or ACK bits set.
setup TCP packets only. Match packets that have the SYN
bit set but no ACK bit.
tcpflags spec
TCP packets only. Match if the TCP header
contains the comma-separated list of flags
specified in spec. The supported TCP flags are:
fin, syn, rst, psh, ack, and urg. The absence of a
particular flag may be denoted with a '!'. A rule
that contains a tcpflags specification can never
match a fragmented packet that has a non-zero
offset. See the frag option for details on
matching fragmented packets.
icmptypes types
ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any
combination of ranges or individual types
separated by commas. Both the numeric values and
the symbolic values listed below can be used. The
supported ICMP types are:
echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17),
and address mask reply (18).
There is one kind of packet that the access device MUST always
discard, that is an IP fragment with a fragment offset of one. This
is a valid packet, but it only has one use, to try to circumvent
firewalls.
An access device that is unable to interpret or apply a deny rule
MUST terminate the session. An access device that is unable to
interpret or apply a permit rule MAY apply a more restrictive rule.
An access device MAY apply deny rules of its own before the supplied
rules, for example to protect the access device owner's
infrastructure.
4.4. Grouped AVP Values
The Diameter protocol allows AVP values of type 'Grouped'. This
implies that the Data field is actually a sequence of AVPs. It is
possible to include an AVP with a Grouped type within a Grouped type,
that is, to nest them. AVPs within an AVP of type Grouped have the
same padding requirements as non-Grouped AVPs, as defined in
Section 4.4.
The AVP Code numbering space of all AVPs included in a Grouped AVP is
the same as for non-Grouped AVPs. Receivers of a Grouped AVP that
does not have the 'M' (mandatory) bit set and one or more of the
encapsulated AVPs within the group has the 'M' (mandatory) bit set
MAY simply be ignored if the Grouped AVP itself is unrecognized. The
rule applies even if the encapsulated AVP with its 'M' (mandatory)
bit set is further encapsulated within other sub-groups, i.e., other
Grouped AVPs embedded within the Grouped AVP.
Every Grouped AVP definition MUST include a corresponding grammar,
using ABNF [RFC5234] (with modifications), as defined below.
grouped-avp-def = "<" name ">" "::=" avp
name-fmt = ALPHA *(ALPHA / DIGIT / "-")
name = name-fmt
; The name has to be the name of an AVP,
; defined in the base or extended Diameter
; specifications.
avp = header *fixed *required *optional
header = "<" "AVP-Header:" avpcode [vendor] ">"
avpcode = 1*DIGIT
; The AVP Code assigned to the Grouped AVP.
vendor = 1*DIGIT
; The Vendor-ID assigned to the Grouped AVP.
; If absent, the default value of zero is
; used.
4.4.1. Example AVP with a Grouped Data Type
The Example-AVP (AVP Code 999999) is of type Grouped and is used to
clarify how Grouped AVP values work. The Grouped Data field has the
following CCF grammar:
Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]
An Example-AVP with Grouped Data follows.
The Origin-Host AVP (Section 6.3) is required. In this case:
Origin-Host = "example.com".
One or more Session-Ids must follow. Here there are two:
Session-Id =
"grump.example.com:33041;23432;893;0AF3B81"
Session-Id =
"grump.example.com:33054;23561;2358;0AF3B82"
optional AVPs included are
Recovery-Policy = <binary>
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
Futuristic-Acct-Record = <binary>
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841
The data for the optional AVPs is represented in hexadecimal form
since the format of these AVPs is not known at the time of definition
of the Example-AVP group nor (likely) at the time when the example
instance of this AVP is interpreted -- except by Diameter
implementations that support the same set of AVPs. The encoding
example illustrates how padding is used and how length fields are
calculated. Also, note that AVPs may be present in the Grouped AVP
value that the receiver cannot interpret (here, the Recover-Policy
and Futuristic-Acct-Record AVPs). The length of the Example-AVP is
the sum of all the length of the member AVPs, including their
padding, plus the Example-AVP header size.
This AVP would be encoded as follows:
0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 496 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 49 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
80 | Session-Id AVP Header (AVP Code = 263), Length = 50 |
+-------+-------+-------+-------+-------+-------+-------+-------+
88 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
120| '5' | '8' | ';' | '0' | 'A' | 'F' | '3' | 'B' |
+-------+-------+-------+-------+-------+-------+-------+-------+
128| '8' | '2' |Padding|Padding| Recovery-Policy Header (AVP |
+-------+-------+-------+-------+-------+-------+-------+-------+
136| Code = 8341), Length = 223 | 0x21 | 0x63 | 0xbc | 0x1d |
+-------+-------+-------+-------+-------+-------+-------+-------+
144| 0x0a | 0xd8 | 0x23 | 0x71 | 0xf6 | 0xbc | 0x09 | 0x48 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
352| 0x8c | 0x7f | 0x92 |Padding| Futuristic-Acct-Record Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
328|(AVP Code = 15930),Length = 137| 0xfe | 0x19 | 0xda | 0x58 |
+-------+-------+-------+-------+-------+-------+-------+-------+
336| 0x02 | 0xac | 0xd9 | 0x8b | 0x07 | 0xa5 | 0xb8 | 0xc6 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
488| 0xe4 | 0x99 | 0x68 | 0xf8 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
4.5. Diameter Base Protocol AVPs
The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, and possible flag values. Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity.
+----------+
| AVP Flag |
| rules |
|----+-----|
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
Acct- 85 9.8.2 Unsigned32 | M | V |
Interim-Interval | | |
Accounting- 483 9.8.7 Enumerated | M | V |
Realtime-Required | | |
Acct- 50 9.8.5 UTF8String | M | V |
Multi-Session-Id | | |
Accounting- 485 9.8.3 Unsigned32 | M | V |
Record-Number | | |
Accounting- 480 9.8.1 Enumerated | M | V |
Record-Type | | |
Acct- 44 9.8.4 OctetString| M | V |
Session-Id | | |
Accounting- 287 9.8.6 Unsigned64 | M | V |
Sub-Session-Id | | |
Acct- 259 6.9 Unsigned32 | M | V |
Application-Id | | |
Auth- 258 6.8 Unsigned32 | M | V |
Application-Id | | |
Auth-Request- 274 8.7 Enumerated | M | V |
Type | | |
Authorization- 291 8.9 Unsigned32 | M | V |
Lifetime | | |
Auth-Grace- 276 8.10 Unsigned32 | M | V |
Period | | |
Auth-Session- 277 8.11 Enumerated | M | V |
State | | |
Re-Auth-Request- 285 8.12 Enumerated | M | V |
Type | | |
Class 25 8.20 OctetString| M | V |
Destination-Host 293 6.5 DiamIdent | M | V |
Destination- 283 6.6 DiamIdent | M | V |
Realm | | |
Disconnect-Cause 273 5.4.3 Enumerated | M | V |
Error-Message 281 7.3 UTF8String | | V,M |
Error-Reporting- 294 7.4 DiamIdent | | V,M |
Host | | |
Event-Timestamp 55 8.21 Time | M | V |
Experimental- 297 7.6 Grouped | M | V |
Result | | |
-----------------------------------------|----+-----|
+----------+
| AVP Flag |
| rules |
|----+-----|
AVP Section | |MUST |
Attribute Name Code Defined Data Type |MUST| NOT |
-----------------------------------------|----+-----|
Experimental- 298 7.7 Unsigned32 | M | V |
Result-Code | | |
Failed-AVP 279 7.5 Grouped | M | V |
Firmware- 267 5.3.4 Unsigned32 | | V,M |
Revision | | |
Host-IP-Address 257 5.3.5 Address | M | V |
Inband-Security | M | V |
-Id 299 6.10 Unsigned32 | | |
Multi-Round- 272 8.19 Unsigned32 | M | V |
Time-Out | | |
Origin-Host 264 6.3 DiamIdent | M | V |
Origin-Realm 296 6.4 DiamIdent | M | V |
Origin-State-Id 278 8.16 Unsigned32 | M | V |
Product-Name 269 5.3.7 UTF8String | | V,M |
Proxy-Host 280 6.7.3 DiamIdent | M | V |
Proxy-Info 284 6.7.2 Grouped | M | V |
Proxy-State 33 6.7.4 OctetString| M | V |
Redirect-Host 292 6.12 DiamURI | M | V |
Redirect-Host- 261 6.13 Enumerated | M | V |
Usage | | |
Redirect-Max- 262 6.14 Unsigned32 | M | V |
Cache-Time | | |
Result-Code 268 7.1 Unsigned32 | M | V |
Route-Record 282 6.7.1 DiamIdent | M | V |
Session-Id 263 8.8 UTF8String | M | V |
Session-Timeout 27 8.13 Unsigned32 | M | V |
Session-Binding 270 8.17 Unsigned32 | M | V |
Session-Server- 271 8.18 Enumerated | M | V |
Failover | | |
Supported- 265 5.3.6 Unsigned32 | M | V |
Vendor-Id | | |
Termination- 295 8.15 Enumerated | M | V |
Cause | | |
User-Name 1 8.14 UTF8String | M | V |
Vendor-Id 266 5.3.3 Unsigned32 | M | V |
Vendor-Specific- 260 6.11 Grouped | M | V |
Application-Id | | |
-----------------------------------------|----+-----|
(next page on part 3)