INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-diameter-04.txt Allan C. Rubens
Date: July 1998 Ascend Communications
DIAMETER
Base Protocol
<draft-calhoun-diameter-04.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The DIAMETER base protocol is intended to provide a framework for any
services which require AAA/Policy support. The protocol is inteded to
be flexible enough to allow services to add building blocks to
DIAMETER in order to meet their requirements.
This draft MUST be supported by all DIAMETER implementations,
regardless of the specific underlying service.
Calhoun, Rubens expires January 1999 [Page 1]
INTERNET DRAFT July 1998
Table of Contents
1.0 Introduction
1.1 Definitions
1.2 Terminology
2.0 Protocol Overview
2.1 Header Format
2.2 AVP Format
3.0 DIAMETER AVPs
3.1 DIAMETER-Command AVP
3.1.1 Unrecognized-Command-Ind
3.1.2 Device-Reboot-Ind
3.1.3 Device-Watchdog-Ind
3.1.4 Device-Feature-Query
3.1.5 Device-Feature-Reply
3.1.6 Device-Config-Req
3.1.7 Device-Config-Answer
3.2 Host-IP-Address
3.3 Host-Name
3.4 Version-Number
3.5 Extension-Id
3.6 Integrity-Check-Vector
3.7 Digital-Signature
3.8 Initialization-Vector
3.9 Timestamp
3.10 Session-Id
3.11 X509-Certificate
3.12 X509-Certificate-URL
3.13 Vendor-Name
3.14 Firmware-Revision
3.15 Result-Code
3.16 Error-Code
3.17 Unrecognized-Command-Code
3.18 Reboot-Type
3.19 Reboot-Timer
3.20 Message-Timer
3.21 Message-In-Progress-Timer
3.22 Message-Retry-Count
3.23 Message-Forward-Count
3.24 Receive-Window
4.0 Protocol Definition
4.1 DIAMETER Bootstrap Message
4.2 Keepalive Exchange
4.3 Unrecognized Command Support
4.4 The art of AVP Tagging
4.5 Device Configuration
4.6 Data Integrity
4.6.1 Using the Integrity-Check-Vector
Calhoun, Rubens expires January 1999 [Page 2]
INTERNET DRAFT July 1998
4.6.2 Using Digital Signatures
4.6.3 Using Mixed Data Integrity AVPs
4.7 AVP Data Encryption
4.7.1 AVP Encryption with Shared Secrets
4.7.2 AVP Encryption with Public Keys
4.8 Public Key Cryptography Support
4.8.1 X509-Certificate
4.8.2 X509-Certificate-URL
4.8.3 Static Public Key Configuration
5.0 References
6.0 Acknowledgements
7.0 Author's Address
1.0 Introduction
Since the RADIUS protocol is being used today for much more than
simple authentication and accounting of dial-up users (i.e.
authentication of WWW clients, etc), a more extensible protocol was
necessary which could support new services being deployed in the
internet and corporate networks.
RADIUS in itself is not an extensible protocol largely due to its
very limited command and attribute address space. In addition, the
RADIUS protocol assumes that there cannot be any unsolicited messages
from a server to a client. In order to support new services it is
imperative that a server be able to send unsolicited messages to
clients on a network, and this is a requirement for any DIAMETER
implementation.
This document describes the base DIAMETER protocol. This document in
itself is not complete and MUST be used with an accompanying
applicability extension document.
An example of such a document would be [7] which defines extensions
to the base protocol to support user authentication and [XXX] which
defines extensions to support accounting.
1.1 Definitions
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the
specification.
Calhoun, Rubens expires January 1999 [Page 3]
INTERNET DRAFT July 1998
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that
there may exist valid reasons in particular circumstances
to ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementation
which does include the option.
1.2 Terminology
AVP
The DIAMETER protocol consists of a header followed by objects.
Each object is encapsulated in a header known as an Attribute-
Value-Pair (AVP).
DIAMETER Device
A Diameter device is a client or server system that supports the
Diameter Base protocol and 0 or more extensions.
ICV
An Integrity Check Vector (ICV) is a hash of the packet with a
shared secret.
2.0 Protocol Overview
There are two different types of DIAMETER messages; A DIAMETER
message that only contains the header and no AVPs is known as a zero
length body message (ZLB). ZLB messages are used for explicitly
acknowledging packets to the peer. non-ZLB DIAMETER messages are
messages that contain AVPs can be of any type defined in [10].
The Identifier field in the DIAMETER header is a monotonically
increasing four octet value that is used to aid in matching requests
with replies. When sending a message to a peer, the sender must
include a value that is unique to itself at that time. The response
to the message from the peer MUST include the same identifier value.
Calhoun, Rubens expires January 1999 [Page 4]
INTERNET DRAFT July 1998
It is imperative that no two outstanding requests from a DIAMETER
node have the same identifier value. Given the current size of the
identifier (2^32), it is highly unlikely that this could occur.
It is not necessary to ensure that identifier messages are unique
across reboots, as long as the DIAMETER node issues a Device-Reboot-
Ind message after reboot completion.
A DIAMETER implementation SHOULD keep transmitted requests in a queue
until a response with the same identifier is received in order to
ensure that it can match the request with the response received.
Two fields in the DIAMETER header that are important to the operation
of DIAMETER are the Nr (Next Received) and Ns (Next Send). A single
sequence number state is maintained for all DIAMETER messages to a
given peer. The Sequence number starts at 0. Each subsequent packet
is sent with the next increment of the sequence number.
The sequence number is thus a free running counter represented modulo
65536. For purposes of detecting duplication, a received sequence
value is considered less than or equal to the last received value if
its value lies in the range of the last value and its 32767 successor
values. For example, if the last received sequence number was 15,
then packets with sequence numbers 0 through 15, as well as 32753
through 65536, would be considered less than or equal to, and would
be silently discarded. Otherwise it would be accepted.
In this document, the sequence number state for each peer is
represented for clarity in the following discussions by distinct
pairs of state variables, Sr and Ss. Sr represents the value of the
next in-sequence messages expected to be received for a given session
by a peer. Ss represents the sequence number to be placed in the Ns
field of the next message sent to a given peer. Each state is
initialized such that the first message sent and the first message
expected to be received for to/from each peer has an Ns value of 0.
This corresponds to initializing the Ss and Sr to 0 for each peer.
As messages are sent to a given peer, Nr is set in these messages to
reflect one more than the Ns value of the highest (modulo 2^16) in-
order message received by that peer; if sent before any packet is
received Nr will be 0, indicating that the peer expects to next new
Ns value to be 0.
When a non-ZLB message is received with an Ns value that matches the
peer's current Sr value, Sr is incremented by 1 (modulo 2^16). It is
important to note that Sr is not modified if a message is received
with a value if Ns greater than the current Sr value. Retransmission
of lost packets should eventually provide the receiving peer with the
Calhoun, Rubens expires January 1999 [Page 5]
INTERNET DRAFT July 1998
expected message.
Everytime a peer sends a non-ZLB message it increments its
corresponding Ss value for that session by 1 (modulo 2^16). This
increment takes place after the current Ss value is copied to Ns in
the message to be sent. Outgoing messages always include the current
value of Sr for the corresponding peer in their Nr field.
A ZLB message indicates that the packet is only used to communicate
Nr and Ns fields. The Nr and the Ns fields are filled in as above,
but the sequence number state, Ss, is not incremented. Thus a ZLB
message sent after a non-ZLB message will contain the new Ns value
while the non-ZLB message sent after a ZLB message with contain the
same value of Ns as the preceding ZLB message.
Upon receipt of an in-order non-ZLB message, the receiving peer must
acknowledge the message by sending back the updated value of Sr in
the Nr field of the next outgoing message. This updated Sr value can
be piggybacked in the Nr field of any non-ZLB ougoing messages that
the peer may happen to send back.
If the peer does not have a message to transmit for a short period of
time after receiving a non-ZLB message then it should send a ZLB
message containing the latest values of Sr and Ss, as described
above. The suggested value for this time interval is 1/4 the
receiving peer's value of Round-Trip-Time (RTT - see Appendix A), if
it computes RTT, or a maximum of 1/2 of its fixed timeout interval
otherwise. This timeout should provide a reasonable opportunity for
the receiving peer to obtain a payload message destined for its peer,
upon which the ACK of the received message can be piggybacked.
This timeout value should be treated as suggested maximum; an
implementation could make this timeout quite small without adversely
affecting the protocol. To provide for better throughput, the
receiving peer should skip this timeout entirely and send a ZLB
message immediately in the case where its receive window fills and it
has no queued data to send for this connection or it can't send
queued data because the transmit window is closed.
A suggested implementation of this timer is as follows: Upon
receiving a non-ZLB message, the receiver starts a timer that will
expire in the recommended time interval. A variable, Lr (Last Nr
value sent), is used by the transmitter to store the last value sent
in the Nr field of a transmitted payload message for this connection.
Upon expiration of this timer, Sr is compared to Lr and, if they are
not equal, a ZLB ACK is issued. If they are equal, then no ACK's are
outstanding and no action needs to be taken.
Calhoun, Rubens expires January 1999 [Page 6]
INTERNET DRAFT July 1998
This timer should not be reinitialized if a new message is received
while it is active since such messages will be acknowledged when the
timer expires. This ensures that periodic ACK's are issued with a
maximum period equal to the recommended timeout interval. This
interval should be short enough to not cause false acknowledgement
timeouts at the transmitter when payload messages are being sent in
one direction only. Since such ACK's are being sent on what would
otherwise be an idle data path, their affect on performance should be
small, of not negligible.
See Appendix A for some examples of how sequence numbers progress.
2.1 Header Format
DIAMETER packets MAY be transmitted over UDP or TCP. Each Service
Extensions draft SHOULD specify the transport layer. The destination
port field for DIAMETER is 1812.
For UDP, when a reply is generated the source and destination ports
are reversed.
A summary of the DIAMETER data format is shown below. The fields are
transmitted from left to right.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIUS PCC |PKT Flags| Ver | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Send (Ns) | Next Received (Nr) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
RADIUS PCC (Packet Compatibility Code)
The RADIUS PCC field is a one octet field which is used for
RADIUS backward compatibility. In order to easily distinguish
DIAMETER packets from RADIUS a special value has been reserved and
allows an implementation to support both protocols concurently
using the first octet in the header. The RADIUS PCC field MUST be
set as follows:
254 DIAMETER packet
Calhoun, Rubens expires January 1999 [Page 7]
INTERNET DRAFT July 1998
PKT Flags
The Packet Flags field is five bits, and is used in order to
identify any options. This field MUST be initialized to zero. The
following flag may be set:
Window-Present 0x1
When set, the Next Send and Next Received fields are
present. This MUST be set unless the underlying layer
provides reliability (i.e. TCP).
Version
The Version field is three bits, and indicates the version number
which is associated with the packet received. This field MUST be
set to 1 to indicate DIAMETER Version 1.
Packet Length
The Packet Length field is two octets. It indicates the length of
the packet including the header fields. For messages received via
UDP, octets outside the range of the Length field should be
treated as padding and should be ignored upon receipt.
Identifier
The Identifier field is four octets, and aids in matching requests
and replies. The sender MUST ensure that the identifier in a
message is locally unique (to the sender) at any given time, and
MAY attempt to ensure that the number is unique across reboots.
The identifier is normally a monotonically increasing number, but
using a random value is also permitted. Given the size of the
Identifier field it is unlikely that 2^32 requests could be
outstanding at any given time.
Next Send
This field is present when the Window-Present bit is set in the
header flags. The Next Send (Ns) is copied from the send sequence
number state variable, Ss, at the time the message is transmitted.
Ss is incremented after copying if the message is not a ZLB ACK.
Next Received
This field is present when the Window-Present bit is set in the
header flags. Nr is copied from the receive sequence number state
variable, Sr, and indicates the sequence number, Ns, +1 of the
Calhoun, Rubens expires January 1999 [Page 8]
INTERNET DRAFT July 1998
highest (modulo 2^16) in-sequence message received. See section
2.0 for more information.
AVPs
AVPs is a method of encapsulating information relevant to the
DIAMETER message. See section 2.2 for more information on AVPs.
2.2 AVP Format
DIAMETER Attributes carry specific authentication, accounting and
authorization information as well as configuration details for the
request and reply.
Some Attributes MAY be listed more than once. The effect of this is
Attribute specific, and is specified in each case by the attribute
description.
Each AVP MUST be padded to align on a 32 bit boundary. Although this
is not problematic for most attribute types, it does require that AVP
of string and data type be padded accordingly. The Padding size can
be calculated using the following formula:
if( Length mod 4 != 0 )
padding_size = 4 - ( Length mod 0 )
else
padding_size = 0
The end of the list of attributes is defined by the length of the
DIAMETER packet minus the length of the header.
The attribute format is shown below and MUST be sent 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (opt) | Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
Calhoun, Rubens expires January 1999 [Page 9]
INTERNET DRAFT July 1998
The AVP Code field is four octets. The first 256 AVP numbers are
reserved for backward RADIUS compatibility. Up-to-date values of
the RADIUS Type field are specified in the most recent "Assigned
Numbers" RFC [2].
AVP numbers 256 and above are used for DIAMETER. Each service MUST
allocate AVP numbers through the IANA.
If the Vendor-Specific-AVP flag is set, the AVP Code is allocated
from the vendor's private address space.
AVP Length
The AVP Length field is two octets, and indicates the length of
this Attribute including the Address Type, AVP Length, AVP Flags,
Reserved, Vendor ID if present and the AVP data. If a packet is
received with an Invalid attribute length, the packet SHOULD be
rejected.
Reserved
The Reserved field MUST be set to zero (0).
AVP Flags
The AVP Flags field informs the DIAMETER host how each attribute
must be handled.
The 'M' Bit, known as the Mandatory bit, indicates whether support
of the AVP is required. If an AVP is received with the 'M' bit
enabled and the receiver does not support the AVP, the request
MUST be rejected.
AVPs without the 'M' bit enabled are informational only and a
receiver that receives a message with such an AVP that is not
supported MAY simply ignore the AVP.
When the 'H' bit is enabled it indicates that the AVP data is
encrypted using hop-by-hop encryption. See section 4.5 for more
information.
When the 'E' bit is enabled it indicates that the AVP data is
encrypted using end-to-end encryption. See section 4.5 for more
information.
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
Calhoun, Rubens expires January 1999 [Page 10]
INTERNET DRAFT July 1998
space.
The 'T' bit, known as the Tag bit, is used to group sets of AVPs
together. Grouping of AVPs is necessary when more than one AVP is
needed to express a condition.
The 'P' bit, known as the protected AVP bit, is used to indicate
whether the AVP is protected by a Digital Signature AVP. When set,
the AVP is protected and the contents cannot be changed by a
DIAMETER proxy server.
Vendor ID
The optional four octet Vendor ID field contains the the IANA
assigned "SMI Network Management Private Enterprise Codes" value,
encoded in network byte order. Any vendor wishing to implement
DIAMETER extensions can use their own Vendor ID along with private
Attribute values, guaranteeing that they will not collide with any
other vendor's extensions, nor with future IETF extensions.
The value zero, reserved in this protocol, corresponds to IETF
adopted Attribute values, defined within this document; zero MUST
NOT be used in an AVP.
Data
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 value field MAY be one of six data types. It is
possible for an attribute to have a structure and this MUST be
defined along with the attribute.
Data
0-65526 octets of arbitrary data.
String
0-65526 octets of string data using the UTF-8 character set.
Address
32 bit or 48 bit value, most significant octet first. The
length of the attribute is determined by the length.
Calhoun, Rubens expires January 1999 [Page 11]
INTERNET DRAFT July 1998
Integer32
32 bit value, most significant octet first.
Integer64
64 bit value, most significant octet first.
Time
32 bit value, most significant octet first -- seconds since
00:00:00 GMT, January 1, 1970.
3.0 DIAMETER AVPs
This section will define the mandatory AVPs which MUST be supported
by all DIAMETER implementations. Note the first 256 AVP numbers are
reserved for RADIUS compatibility.
The following AVPs are defined in this document:
Attribute Name Attribute Code
-----------------------------------
DIAMETER-Command 256
Host-IP-Address 4
Host-Name 32
Version-Number 257
Extension-Id 258
Integrity-Check-Vector 259
Digital-Signature 260
Initialization-Vector 261
Timestamp 262
Session-Id 263
X509-Certificate 264
X509-Certificate-URL 265
Vendor-Name 266
Firmware-Revision 267
Result-Code 268
Error-Code 269
Unknown-Command-Code 270
Reboot-Type 271
Reboot-Timer 272
Message-Timer 273
Message-In-Progress-Timer 274
Message-Retry-Count 275
Maximum-Forward-Count 276
Receive-Window 277
Calhoun, Rubens expires January 1999 [Page 12]
INTERNET DRAFT July 1998
3.1 DIAMETER-Command AVP
Description
The Command AVP MUST be the first AVP following the DIAMETER
header. This AVP is used in order to communicate the command
associated with the message. There MUST only be a single Command
AVP within a given message. The format of the AVP is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER-Command
AVP Length
The length of this attribute MUST be at least 12. The exact length
of the AVP is determined by the actual Command and is defined with
each command.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon
the security model used. The 'V' MAY be set if the Command Code is
vendor specific. The 'T' and the 'U' bits MUST NOT be set.
Command Code
The Command Code field contains the command number. The following
commands are defined and MUST be supported by all DIAMETER
implementations in order to conform to the base protocol
specification:
Command Name Command Code
-----------------------------------
Command-Unrecognized-Ind 256
Device-Reboot-Ind 257
Device-Watchdog-Ind 258
Device-Feature-Query 259
Calhoun, Rubens expires January 1999 [Page 13]
INTERNET DRAFT July 1998
Device-Feature-Reply 260
Device-Config-Request 304
Device-Config-Answer 305
3.1.1 Command-Unrecognized-Ind (CUI)
Description
Messages with the Command-Unrecognized AVP MUST be sent by a
DIAMETER device to inform its peer that a message was received
with an unsupported Command AVP value.
Since there certainly will exist a case where an existing device
does not support a new extension to the DIAMETER protocol, a
device which receives a packet with an unrecognized Command code
MUST return a Command-Unrecognized packet.
This Command MUST also include the Unknown-Command-Code AVP.
A summary of the Command-Unrecognized packet format is shown
below. The fields are transmitted from left to right.
Message Format
<Unrecognized-Command-Ind> ::= <DIAMETER Header>
<Unrecognized-Command-Ind Command AVP>
<Unrecognized-Command-Code AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
Calhoun, Rubens expires January 1999 [Page 14]
INTERNET DRAFT July 1998
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V' MAY be set if the Command
Code is vendor specific. The 'T' and the 'U' bits MUST NOT be
set.
Command Code
The Command Code field MUST be set to 256 (Command-
Unrecognized-Ind).
3.1.2 Device-Reboot-Ind (DRI)
Description
The Device-Reboot-Indication message is sent by a DIAMETER device
to inform all of its peers either of an upcoming reboot or that it
has just rebooted.
The Reboot-Type AVP MUST be present and indicates the type of
reboot associated with this command. The peer MUST respond to the
message with a successful acknowledgement. Note that a DIAMETER
device should only send this message once it is able to receive
network traffic.
This message is also used by a DIAMETER device in order to
exchange the supported protocol version number as well as all
supported extensions. The originator of this message MUST insert
it's highest supported version number within the DIAMETER header.
The response message MUST include the highest supported version up
to and including the version number within the request.
Similarly the originator of this message MUST include all
supported extensions within the message. The responder MUST
include all supported extensions as long as they were present
within the request message.
In the case where the receiver of this message is a proxy device,
it is responsible for inserting the highest version number which
it supports in the version field before sending the proxy request
Calhoun, Rubens expires January 1999 [Page 15]
INTERNET DRAFT July 1998
to the remote DIAMETER peer. The proxy device may then retain the
version number of the remote peers as received in the message, and
must insert its highest version number (with the limitations
described above) in the response to the initiator.
It is desireable for a DIAMETER device to retain the supported
extensions as well as the version number in order to ensure that
any requests issued to a peer will be processed.
This message MUST contain the Receive-Window AVP and MAY contain
the Version-Number, Vendor-Name and Extension-Id AVPs.
In the case where a DIAMETER device is configured to communicate
with many peers, this message MUST be issued to each peer.
No explicit DIAMETER message is necessary to acknowledge this
message since it is handled by DIAMETER's reliable transport.
Message Format
<Device-Reboot-Ind> ::= <DIAMETER Header>
<Device-Reboot-Ind Command AVP>
<Reboot-Type AVP>
[<Reboot-Time AVP>]
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Vendor-Name AVP>
<Firmware-Revision AVP>
[<X509-Certificate AVP>]
[<X509-Certificate-URL AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
Calhoun, Rubens expires January 1999 [Page 16]
INTERNET DRAFT July 1998
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 257 (Device-Reboot-
Indication).
3.1.3 Device-Watchdog-Ind (WDI)
Description
The Device-Watchdog-Ind is used as a keepalive mechanism between
two DIAMETER peers. The request MUST include the Sequence-Number
AVP which is a monotonically increasing number and used to
identify loss of connectivity. This message MUST contain the
Host-IP-Address or Host-Name AVP as well as any security related
AVPs.
No explicit DIAMETER message is necessary to acknowledge this
message since it is handled by DIAMETER's reliable transport.
Message Format
<Device-Watchdog-Ind> ::= <DIAMETER Header>
<Device-Watchdog-Ind Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Rubens expires January 1999 [Page 17]
INTERNET DRAFT July 1998
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 258 (Device-Watchdog-
Ind).
3.1.4 Device-Feature-Query (DFQ)
Description
The Device-Feature-Query message is used in order to query a peer
about it's supported extensions. This message MAY contain the
Version-Number, Vendor-Name and Extension-Id AVPs.
Message Format
<Device-Feature-Query> ::= <DIAMETER Header>
<Device-Feature-Query Command AVP>
[<Version-Number>]
[<Vendor-Name>]
[<Extension-Id>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
Calhoun, Rubens expires January 1999 [Page 18]
INTERNET DRAFT July 1998
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 259 (Device-Feature-
Request).
3.1.5 Device-Feature-Reply (DFR)
Description
The Device-Feature-Reply message is sent in response to the
Device-Feature-Query message. This message includes all supported
extensions by the responder and MAY contain the Version-Number,
Vendor-Name and Extension-Id AVPs.
Message Format
<Device-Feature-Reply> ::= <DIAMETER Header>
<Device-Feature-Reply Command AVP>
[<Version-Number>]
[<Vendor-Name>]
<Extension-Id>
<Timestamp AVP>
<Initialization-Vector AVP>
Calhoun, Rubens expires January 1999 [Page 19]
INTERNET DRAFT July 1998
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 260 (Device-Feature-
Reply).
3.1.6 Device-Config-Request (DCR)
Description
The Device-Config-Request message is sent by a DIAMETER device to
provide configuration information to peers under administrative
control of the sender. Peers receiving this information SHOULD use
it when communicating with the originator of this message. The
peer MUST respond to the message with a Device-Config-Answer.
This message MAY contain vendor specific AVPs which MAY be ignored
by the receiver.
Calhoun, Rubens expires January 1999 [Page 20]
INTERNET DRAFT July 1998
Message Format
<Device-Config-Request> ::= <DIAMETER Header>
<Device-Config-Request Command AVP>
<Session-Id AVP>
[<Message-Timer>]
[<MessageInProgress-Timer>]
[<Message-Retry-Count>]
[<Maximum-Forward-Count>]
[<Extension-Id>]
[<Version-Number>]
[<Vendor-Name>]
[<Vendor-Specific AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 304 (Device-Config-
Request).
Calhoun, Rubens expires January 1999 [Page 21]
INTERNET DRAFT July 1998
3.1.7 Device-Config-Answer (DCA)
Description
The Device-Config-Answer message is sent by a DIAMETER device to
acknowledge receipt of the Device-Config-Request message.
The Device-Config-Answer message MUST contain the Result-Code AVP
to indicate whether the configuration was accepted. The Result-
Code MAY be used to indicate refusal of any of the AVPs in the
request.
The Device-Config-Answer message MAY contain configuration AVPs
and if they are present it is understood that the receiver has no
way to refuse them.
Message Format
<Device-Config-Answer> ::= <DIAMETER Header>
<Device-Config-Answer Command AVP>
<Session-Id AVP>
<Response-Code AVP>
[<Message-Timer AVP>]
[<MessageInProgress-Timer AVP>]
[<Message-Retry-Count AVP>]
[<Maximum-Forward-Count AVP>]
[<Extension-Id AVP>]
[<Version-Number AVP>]
[<Vendor-Name AVP>]
[<Vendor-Specific AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
Calhoun, Rubens expires January 1999 [Page 22]
INTERNET DRAFT July 1998
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 305 (Device-Config-
Answer).
3.2 Host-IP-Address
Description
The Host-IP-Address attribute is used to inform a DIAMETER peer of
the sender's identity.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
4 Host-IP-Address
AVP Length
The length of this attribute MUST be at least 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
Calhoun, Rubens expires January 1999 [Page 23]
INTERNET DRAFT July 1998
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Address
The Address field contains the sender's IP address.
3.3 Host-Name
Description
The Host-Name attribute is used to inform a DIAMETER peer of the
sender's identity.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
AVP Code
32 Host-Name
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
The String field is one or more octets, and should be unique to
the DIAMETER host. The Host Name MUST follow the NAI [8] naming
conventions.
Calhoun, Rubens expires January 1999 [Page 24]
INTERNET DRAFT July 1998
3.4 Version-Number
Description
The Version-Number AVP is used in order to indicate the current
DIAMETER system version number to a peer.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
257 Version-Number
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field contains the system's DIAMETER version
number.
3.5 Extension-Id
Description
The Extension-Id AVP is used in order to identify a specific
DIAMETER extension. This AVP MAY be used in the Device-Reboot-Ind
and the Device-Feature-Reply command in order to inform the peer
what externsions are locally supported.
Calhoun, Rubens expires January 1999 [Page 25]
INTERNET DRAFT July 1998
Each DIAMETER extensions draft MUST have a Extension-Id assigned
to it by the IANA. The base protocol does not require a
Extension-Id since its support is mandatory.
There MAY be more than one Extension-Id AVP within a DIAMETER
message.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
258 Extension-Id
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field contains the extension identifier as
defined in the extension's document.
3.6 Integrity-Check-Vector
Description
The Integrity-Check-Vector AVP is used for hop-by-hop
authentication and integrity, and is not recommended for use with
untrusted proxy servers.
The DIAMETER header as well as all AVPs up to and including the
Calhoun, Rubens expires January 1999 [Page 26]
INTERNET DRAFT July 1998
AVP Code field of this AVP is protected by the Integrity-Check-
Vector. The Timestamp AVP MUST be present to provide replay
protection and the Initialization-Vector AVP must be present to
add randomness to the packet.
The Integrity-Check-Vector is generated in the method described in
section 4.5.1.
All DIAMETER implementations MUST support this AVP.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
259 Integrity-Check-Vector
AVP Length
The length of this attribute MUST be at least 13.
AVP Flags
The 'M' bit MUST be set. The 'E', 'H', 'V', 'T' and the 'U'
bits MUST NOT be set.
Transform ID
The Transform ID field contains a value that identifies the
transform that was used to compute the ICV. The following
values are defined in this document:
HMAC-MD5-96[6] 1
Data
The Data field contains an ICV of the message up to this AVP.
Calhoun, Rubens expires January 1999 [Page 27]
INTERNET DRAFT July 1998
3.7 Digital-Signature
Description
The Digital-Signature AVP is used for authentication, integrity as
well as non-repudiation. A DIAMETER entity adding AVPs to a
message MUST ensure that all AVPs appear prior to the Digital-
Signature AVP (with the exception of the Integrity-Check-Vector
AVP that MUST appear after the Digital-Signature AVP). The
Timestamp AVP MUST be present to provide replay protection and the
Initialization-Vector AVP must be present to add randomness to the
packet.
The DIAMETER header as well as all AVPs with the 'U' bit disabled
are protected by the Digital-Signature.
In order to support proxy DIAMETER servers, which forwards
messages to next hop server, the proxy server MUST NOT modify any
AVPs with the even through proxy arrangements.
The Digital-Signature is generated in the method described in
section 4.5.2.
All DIAMETER implementations SHOULD support this AVP.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
260 Digital-Signature
AVP Length
The length of this attribute MUST be at least 17.
Calhoun, Rubens expires January 1999 [Page 28]
INTERNET DRAFT July 1998
AVP Flags
The 'M' bit MUST be set. The 'H' MAY be set if the request is
protected with an ICV AVP. The 'E', 'V', 'T' and the 'U' bits
MUST NOT be set.
Address
The Address field contains the IP address of the DIAMETER host
which generated the Digital-Signature.
Transform ID
The Transform ID field contains a value that identifies the
transform that was used to compute the signature. The following
values are defined in this document:
RSA [9] 1
Data
The Data field contains the digital signature of the packet up
to this AVP.
3.8 Initialization-Vector
Description
The Initialization-Vector AVP MUST be present prior to the
Digital- Signature and Integrity-Check-Vector AVPs within a
message and is used to ensure randomness within a message. The
content of this AVP MUST be a random 128 bit value.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
Calhoun, Rubens expires January 1999 [Page 29]
INTERNET DRAFT July 1998
261 Initialization-Vector
AVP Length
The length of this attribute MUST be at least 24.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Data
The Data field contains a random 128 bit value.
3.9 Timestamp
Description
The Timestamp field is used in order to enable replay protection
of previous messages. The value of time is the most significant
four octets returned from an NTP server which indicates the number
of seconds expired since Jan. 1, 1970.
This document does not specify the window which an implementation
will accept packets, however it is strongly encouraged to make
this value user configurable with a reasonable default value (i.e.
4 seconds).
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
262 Timestamp
AVP Length
Calhoun, Rubens expires January 1999 [Page 30]
INTERNET DRAFT July 1998
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Time
The Time field contains the number of seconds since Jan. 1,
1970 when the message was created.
3.10 Session-Id
Description
The Session-Id field is used in order to identify a specific
session. All messages pertaining to a specific session MUST
include this AVP and the same value MUST be used throughout the
life of a session. When present, the Session-Id SHOULD appear
immediately following the Command- AVP.
Note that in some applications there is no concept of a session
(i.e. data flow) and this field MAY be used to identify objects
other than a session.
The Session-Id MUST be globally unique at any given time since it
is used by the server to identify the session (or flow). It is
recommended that the format of the AVP be as follow:
<Sender's IP Address><monotonically increasing 32 bit
value><optional value>
It is suggested that the monotonically increasing 32 bit value NOT
start at zero upon reboot, but rather start at a random value.
This will minimize the possibility of overlapping Session-Ids
after a reboot. The optional value is implementation specific but
may include a modem's device Id, a random value, etc.
The session Id is created by the DIAMETER device initiating the
session. In most cases this is performed by the client. Note that
a Session-Id can be used by more than one extension.
AVP Format
0 1 2 3
Calhoun, Rubens expires January 1999 [Page 31]
INTERNET DRAFT July 1998
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
263 Session-Id
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Data
The Data field contains the session identifier assigned to the
session.
3.11 X509-Certificate
Description
The X509-Certificate is used in order to send a DIAMETER peer the
local system's X.509 certificate chain, which is used in order to
validate the Digital-Signature attribute.
Section 4.7 contains more information about the use of
certificates.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
Calhoun, Rubens expires January 1999 [Page 32]
INTERNET DRAFT July 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+
AVP Code
264 X509-Certificate
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Data
The Data field contains the X.509 Certificate Chain.
3.12 X509-Certificate-URL
Description
The X509-Certificate-URL is used in order to send a DIAMETER peer
a URL to the local system's X.509 certificate chain, which is used
in order to validate the Digital-Signature attribute.
Section 4.7 contains more information about the use of
certificates.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
AVP Code
Calhoun, Rubens expires January 1999 [Page 33]
INTERNET DRAFT July 1998
265 X509-Certificate-URL
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
String
The String field contains the X.509 Certificate Chain URL.
3.13 Vendor-Name
Description
The Vendor-Name attribute is used in order to inform a DIAMETER
peer of the Vendor Name of the DIAMETER device. This MAY be used
in order to know which vendor specific attributes may be sent to
the peer.
It is also envisioned that the combination of the Vendor-Name and
the Firmware-Revision AVPs can provide very useful debugging
information.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ...
+-+-+-+-+-+-+-+-+
AVP Code
266 Vendor-Name
AVP Length
Calhoun, Rubens expires January 1999 [Page 34]
INTERNET DRAFT July 1998
The length of this attribute MUST be at least 9.
AVP Flags
The 'H' and 'E' MAY be set depending upon the security model
used. The
String
The String field contains the vendor name.
3.14 Firmware-Revision
Description
The Firmware-Revision AVP is used to inform a DIAMETER peer of the
firmware revision of the issuing device.
For devices which do not have a firmware revision (general purpose
computers running DIAMETER software modules, for instance), the
revision of the DIAMETER software module may be reported instead.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
267 Firmware-Revision
AVP Length
The length of this attribute MUST be at least 12.
AVP Flags
The 'H' and 'E' MAY be set depending upon the security model
used. The
Calhoun, Rubens expires January 1999 [Page 35]
INTERNET DRAFT July 1998
Integer32
The Integer32 field contains the firmware revision number of
the issuing device.
3.15 Result-Code
Description
The Result-Code AVP is used in order to indicate whether a
particular command was completed successfully or whether an error
occurred. All DIAMETER commands MUST specify whether the Result-
Code AVP MUST be present.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
268 Result-Code
AVP Length
The length of this attribute MUST be at least 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field contains the result code associated with
the DIAMETER command. The following codes have been defined:
DIAMETER_SUCCESS 0
The Request was successfully completed.
Calhoun, Rubens expires January 1999 [Page 36]
INTERNET DRAFT July 1998
DIAMETER_FAILURE 1
The Request was not successfully completed for an
unspecified reason.
DIAMETER_POOR_REQUEST 2
The Request was poorly constructed.
DIAMETER_INVALID_MAC 3
The Request did not contain a valid Integrity-Check-
Vector or Digital- Signature.
DIAMETER_UNKNOWN_SESSION_ID 4
The Request contained an unknown Session-Id.
DIAMETER_SEE_ERROR_CODE 5
The Request failed. See the Error-Code AVP for more info.
3.16 Error-Code
Description
The Error-Code AVP contains the message specific error code, if
any. This AVP only needs to be present if the Result-Code AVP is
present with the DIAMETER_SEE_ERROR_CODE.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
269 Error-Code
AVP Length
The length of this attribute MUST be at least 12.
AVP Flags
Calhoun, Rubens expires January 1999 [Page 37]
INTERNET DRAFT July 1998
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field contains the error code.
3.17 Unknown-Command-Code
Description
The Unknown-Command-Code AVP contains the offending Command Code
that resulted in sending the Unrecognized-Command-Code message.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
270 Unknown-Command-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field contains the unrecognized command code that
resulted in sending an Unrecognized-Command-Code message.
Calhoun, Rubens expires January 1999 [Page 38]
INTERNET DRAFT July 1998
3.18 Reboot-Type
Description
The Reboot-Type AVP MUST be present in the Device-Reboot-
Indication message and contains an indication of the type of
reboot.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
271 Reboot-Type
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field contains the reboot type associated with
the DRI command. The following value are currently defined:
REBOOT_IMMINENT 1
When the Reboot-Type AVP is set to this value it is an
indication that the DIAMETER peer is about to reboot and
should not be sent any additional DIAMETER messages
besides the acknowledgement.
REBOOTED 2
When the Reboot-Type AVP is set to this value it is an
indication that the DIAMETER peer has recently rebooted
Calhoun, Rubens expires January 1999 [Page 39]
INTERNET DRAFT July 1998
and is ready to accept new DIAMETER messages.
CLEAN_REBOOT 3
When the Reboot-Type AVP is set to this value the server
is in the process of shutting down and MAY be available
at some time in the future.
3.19 Reboot-Time
Description
The Reboot-Time AVP MAY be present in the DRI and indicates the
number of seconds before the issuer expects to be ready to receive
new DIAMETER messages. This AVP MUST only be present when the
Reboot-Type AVP is set to REBOOT_IMMINENT. The value indicated by
this AVP should be used as an estimate and is not a hard rule.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
272 Reboot-Time
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
The Integer32 field contains the expected amount of seconds
before the issuer of the DRI expects to be receive to receive
Calhoun, Rubens expires January 1999 [Page 40]
INTERNET DRAFT July 1998
new DIAMETER messages.
3.20 Message-Timer
Description
This AVP is used by a device to determine how long to wait before
trying again to send a message expecting a response or
acknowledgement. This timer value overrides any default value a
device may have.
Note that a DIAMETER extensions AVP could define another timer
that would override this one for a specific message type.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
273 Message-Timer
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
This field contains the value of the timer in milliseconds. A
value of 0 for this timer means that the default value for this
timer is to be used.
Calhoun, Rubens expires January 1999 [Page 41]
INTERNET DRAFT July 1998
3.21 Message-In-Progress-Timer
Description
This AVP is used by a device's state machine to deterimine how
long to wait before sending a MessageInProgress message that tells
the peer device that the message it is expecting a response or
acknowledgment for is still in progress.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
274 Message-In-Progress-Timer
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
This field contains the value of the timer in milliseconds. A
value of 0 indicates that the MessageInProgress-Indication
message is not being used.
3.22 Message-Retry-Count
Description
This AVP is used by a device's state machine to determine how many
times it is allowed to resend a message that is expecting a
Calhoun, Rubens expires January 1999 [Page 42]
INTERNET DRAFT July 1998
response or acknowledgement.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
275 Message-Retry-Count
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
This field contains the value for the counter.
3.23 Maximum-Forward-Count
Description
This AVP is used by a device to determine if a message should
continue to be forwarded. A use for this count would be to limit
the number of proxies used to satisfy a request.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Rubens expires January 1999 [Page 43]
INTERNET DRAFT July 1998
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
276 Maximum-Forward-Count
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
This field contains the value for the counter.
3.24 Receive-Window
Description
This AVP is used by a device to inform a peer of the local receive
window size. The size indicated is the number of packets that it
is willing to accept before the window is full.
AVP Format
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
277 Receive-Window
Calhoun, Rubens expires January 1999 [Page 44]
INTERNET DRAFT July 1998
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'U' bits
MUST NOT be set.
Integer32
This field contains the receive window size.
4.0 Protocol Definition
This section will describe how the base protocol works (or is at
least an attempt to).
4.1 DIAMETER Bootstrap Message
DIAMETER provides a message that is used to indicate either an
imminent reboot, or that a reboot has occurred. The DRI message MUST
be sent to all known DIAMETER peers both previous to a reboot when
possible as well as following a reboot.
The Reboot-Type AVP is used to indicate the type of reboot associated
with the DRI. When set to REBOOT_IMMINENT, all peers should be warned
that any new DIAMETER requests sent to the issuer will probably not
be received or processed. If a request MUST be sent it would be
preferable to issue the request to an alternate peer if available.
The message includes an optional Reboot-Time AVP that specifies an
estimate of how long before the issuer is available to receive new
DIAMETER messages.
Upon reboot, the host MUST issue a DRI message with the Reboot-Type
AVP set to REBOOTED. This is an indication that new DIAMETER messages
may be sent to the transmitter of the DRI.
Note that the Reboot-Time AVP is not required, and when present
provides an estimate and should not be used as a hard value. In the
case of a software implementation (server) running on a general
purpose operating system, the Reboot-Time AVP will probably not be
present since it is possible that the DIAMETER server has been
stopped and it is not possible to know how long before (and if) it
Calhoun, Rubens expires January 1999 [Page 45]
INTERNET DRAFT July 1998
will be restarted.
The DIAMETER Reboot-Ind message does not require a reply. The message
is acknowledged using DIAMETER's reliable transport.
4.2 Keepalive Exchange
DIAMETER uses the Device-Watchdog-Ind message as a keepalive
mechanism. DIAMETER entities that need to ensure that connectivity
with a peer is not lost may use this mechanism.
A DIAMETER Client can use this mechanism to ensure that failover to
an alternate server occurs even without any AAA traffic. Redundant
DIAMETER Servers use this mechanism to identify when the primary
server is no longer available.
The DIAMETER Device-Watchdog-Ind message does not require a reply.
The message is acknowledged using DIAMETER's reliable transport.
4.3 Unrecognized Command Support
The DIAMETER protocol provides a message that is used to inform a
peer that a DIAMETER message was received with an unrecognized
command. The following provides a DIAMETER message that is sent to a
peer:
<Take-A-Hike-Req> ::= <DIAMETER Header>
<Take-A-Hike-Req Command AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
Upon receipt of the above message, the receiver notices that it does
not support the command and sends the following message:
<Unrecognized-Command-Ind> ::= <DIAMETER Header>
<Unrecognized-Command-Ind Command AVP>
<Unrecognized-Command-Code AVP>
<Host-IP-Address AVP>
[<Host-Name AVP>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
Calhoun, Rubens expires January 1999 [Page 46]
INTERNET DRAFT July 1998
<Digital-Signature AVP }
4.4 The art of AVP Tagging
The AVP Header provides the 'T' bit which is used for grouping AVPs
together. Although the base protocol does not define any AVPs that
need to be grouped, it is envisioned that DIAMETER extensions will
require tag support.
In the case where multiple AVPs are needed to indicate a specific
authorization "rule" tagging is appropriate. Such an example is taken
from [14] that discusses Tunneling attributes. In this case multiple
AVPs are required in order to specify tunnel parameter, and more than
one set of AVPs MAY be present in the message. This is necessary in
order to support redundant tunnel servers.
In this case, the AVPs that need to be grouped together would have a
specific tag value, and each group would use a different tag value.
4.5 Device Configuration
DIAMETER provides two messages that can be used by DIAMETER peers in
order to exchange certain configuration information, such as
retransmission timer values. This message MAY be sent at any time and
is not restricted to being sent at boot-up time only.
Upon receipt of the Device-Config-Request, the receiver SHOULD make
use of the configuration information provided when communicating with
the initiator of the message.
The receiver MUST acknowledge receipt of the message with a Device-
Config-Answer which may also contain some configuration information.
Note that if such configuration AVPs are present in the Device-
Config-Answer the peer cannot reply with a success of failure
Result-Code.
A preferable method for two nodes to "negotiate" configuration
information would be for both of them to issue Device-Config-
Requests. However in some applications minimizing packets over the
wire are startup time requires that the Device-Config-Answer carry
such information.
Note that both messages have a high probability of containing vendor
specific AVP which MAY be ignored. Implementations MUST assume that
that receiver does NOT support vendor specific AVPs sent.
Calhoun, Rubens expires January 1999 [Page 47]
INTERNET DRAFT July 1998
4.6 Data Integrity
This section will describe how data integrity is achieved using the
Data Integrity AVPs.
Note that the Timestamp and Initialization-Vector AVPs MUST be
present in the message PRIOR to any of the Data Integrity AVPs
discussed in this section. The Timestamp AVP provides replay
protection and the Initialization-Vector AVP provides randomness.
4.6.1 Using the Integrity-Check-Vector
The use of the Integrity-Check-Vector (ICV) AVP requires a pre-
configured shared secret. Although this mechanism does not scale as
well as the Digital Signature, it may be desireable to use this
mechanism in the case where asymetric technology is not required or
available.
Note that in the case where two DIAMETER nodes need to communicate
through an intermediate node (i.e. Proxy) it does not offer any end-
to-end data integrity or encryption as each node must re-compute the
Integrity-Check-Vector AVP.
The Data field of the AVP contains an HMAC-MD5-96[6] of the message
up to the ICV AVP. Using the example code provided in [6], the
following call would be used to generate the Integrity-Check-Vector:
hmac_md5(DiameterMessage, MessageLength, Secret, Secretlength,
Output)
The following is an example of a message that include hop-by-hop
security:
<DIAMETER Message> ::= <DIAMETER Header>
<Command AVP>
[<Additional AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
<Integrity-Check-Vector AVP>
4.6.2 Using Digital Signatures
In the case of a simple peer to peer relationship the use of IPSEC is
sufficient for data integrity and non-repudiation. However there are
instances where a peer must communicate with another peer through the
use of a proxy server. IPSEC does not provide a mechanism to protect
Calhoun, Rubens expires January 1999 [Page 48]
INTERNET DRAFT July 1998
traffic when two peers must use an intermediary node to communicate
at the application layer therefore the Digital-Signature AVP MUST be
used.
The following diagram shows an example of a router initiating a
DIAMETER message to DIA1. Once DIA1 has finished processing the
message it adds its signature and forwards the message to the non-
trusted DIA2 proxy server. If DIA2 needs to add or change any
protected AVPs it SHOULD add its digital signature before forwarding
the message to DIA3.
+------+ -----> +------+ -----> +------+ -----> +------+
| | | | | non- | | |
|router+----------+ DIA1 +----------+trustd+----------+ DIA3 |
| | | | | DIA2 | | |
+------+ <----- +------+ <----- +------+ <----- +------+
Since some fields within the DIAMETER header will change "en route"
towards the final DIAMETER destination, it is necessary to set the
mutable fields to zero (0) prior to calculating the signature. The
two mutable fields are the identifier and the length in the DIAMETER
header.
The following is an example of a message that include end-to-end
security:
<DIAMETER Message> ::= <DIAMETER Header>
<Command AVP>
[<Additional AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
<Digital-Signature AVP>
The AVP Header's 'P' bit is used to identify which AVPs are
considered protected when applying a digital signature to a DIAMETER
message. Protected AVPs cannot changed "en route" since they are
protected by the Digital Signature AVP. All AVPs added by a DIAMETER
entity MUST appear prior to the Digital Signature AVP that is added
(with the exception of the Integrity-Check-Vector AVP). However, only
AVPs with the 'P' bit set are used in the digital signature
calculation.
The Data field of the Digital-Signature AVP contains the RSA/MD5
signature algorithm as defined in [9].
4.6.3 Using Mixed Data Integrity AVPs
Calhoun, Rubens expires January 1999 [Page 49]
INTERNET DRAFT July 1998
The previous sections described the Integrity-Check-Vector and the
Digital-Signature AVP. Since the ICV offers hop-by-hop integrity and
the digital signature offers end to end integrity, it is possible to
use both AVPs within a single DIAMETER message.
The following diagram provides an example where DIAMETER Server 1
(DIA1) communicates with DIA3 using Digital-Signatures through DIA2.
In this example ICVs are used between DIA1 and DIA2 as well as
between DIA2 and DIA3.
<Public-Key>
----------------------------->
<Shared-Secret> <Shared-Secret>
+------+ -----> +------+ -----> +------+
| | | | | |
| DIA1 +----------+ DIA2 +----------+ DIA3 |
| | | | | |
+------+ +------+ +------+
Using the previous diagram, the following message would be sent
between DIA1 and DIA2:
<DIAMETER Message> ::= <DIAMETER Header>
<Command AVP>
[<Additional AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
<Digital-Signature AVP>
<Integrity-Check-Vector AVP (DIA1->DIA2)>
The following message would be sent between DIA2 and DIA3:
<DIAMETER Message> ::= <DIAMETER Header>
<Command AVP>
[<Additional AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
<Digital-Signature AVP>
<Timestamp AVP>
<Initialization-Vector AVP>
<Integrity-Check-Vector AVP (DIA2->DIA3)>
Note that in the above example messages the ICV AVP appear after the
Digital-Signature AVP. This is necessary since DIA2 above removes the
ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The ICVs
provide hop-by-hop security while the Digital-Signature provides
integrity of the message between DIA1 and DIA3.
Calhoun, Rubens expires January 1999 [Page 50]
INTERNET DRAFT July 1998
<Shared-Secret> <Public-Key>
+------+ -----> +------+ -----> +------+
| | | | | |
|router+----------+ DIA1 +----------+ DIA2 |
| | | | | |
+------+ <----- +------+ <----- +------+
There are cases, such as in remote access, where the device
initiating the DIAMETER request does not have the processing power to
generate Digital-Signatures as required by the protocol. In such an
arrangement, there normally exists a first hop DIAMETER Server (DIA1)
which acts as a proxy to relay the request to the final
authenticating DIAMETER server (DIA2). It is valid for the first hop
server to remove the Integrity-Check-Vector AVP inserted by the
router and replace it with a Digital-Signature AVP.
4.7 AVP Data Encryption
DIAMETER supports two methods of encrypting AVP data. One is using a
shared secret and the other is used with public keys.
This feature can be used to encrypt sensitive data such as user ID's
and passwords. The Encryption bits MUST NOT be set in the Command
Type or Initialization-Vector AVPs.
4.7.1 AVP Encryption with Shared Secrets
This method of encrypting AVP data is the simplest to use and MUST be
supported by all DIAMETER implementations. However, local policy MAY
determine that the use of this mechanism is not permitted.
The SS-Encrypted-Data bit MUST only be set if a shared secret exists
between both DIAMETER peers. If the SS-Encrypted-Data bit is set in
any DIAMETER AVP, the Initialization-Vector AVP MUST be present prior
to the first encrypted AVP.
The length of the AVP value to be encrypted is first encoded in the
following Subformat:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of ClearText Data | ClearText Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Rubens expires January 1999 [Page 51]
INTERNET DRAFT July 1998
Length
The Length field contains the length of the decrypted data.
ClearText Data
Data of AVP that is to be obscured.
Padding
Random additional octets used to obscure length of the ClearText
Data.
The resulting subformat MAY be padded to a multiple of 16 octets in
length. For example, if the ClearText Data to be obscured is a string
containing 6 characters (e.g. password 'foobar'), then 8 + n * 16
octects of padding would be applied. Padding does NOT alter the value
placed in the Length of the ClearText Data, only the length of the
AVP itself.
Next, An MD5 hash is performed on the concatenation of:
- the two octet Command Code of the AVP
- the shared authentication secret
- an arbitrary length random vector
The value of the random vector used in this hash is passed in the
Data field of a Initialization-Vector AVP. This Initialization-
Vector AVP must be placed in the message by the sender before any
hidden AVPs. The same Initialization-Vector may be used for more than
one hidden AVP in the same message. If a different Initialization-
Vector is used for the hiding of subsequent AVPs then a new
Initialization-Vector AVP must be placed before the first AVP to
which it applies.
The MD5 hash value is then XORed with the first 16 octet or less
segment of the AVP Subformat and placed in the Data field of the AVP.
If the AVP Subformat is less than 16 octets, the Subformat is
transformed as if the Value field had been padded to 16 octets before
the XOR, but only the actual octets present in the Subformat are
modified, and the length of the AVP is not altered.
If the Subformat is longer than 16 octets, a second one-way MD5 hash
is calculated over a stream of octets consisting of the shared secret
followed by the result of the first XOR. That hash is XORed with the
second 16 octet or less segment of the Subformat and placed in the
corresponding octets of the Data field of the AVP.
Calhoun, Rubens expires January 1999 [Page 52]
INTERNET DRAFT July 1998
If necessary, this operation is repeated, with each XOR result being
used along with the shared secret to generate the next hash to XOR
the next segment of the value with. This technique results in the
content of the AVP being obscured, although the length of the AVP is
still known.
On receipt, the Initialization-Vector is taken from the last
Initialization-Vector AVP encountered in the message prior to the AVP
to be decrypted. The above process is then reversed to yield the
original value. For more details on this hiding method, consult
RFC2138 [1].
Please note that in the case where the DIAMETER message needs to be
processed by an intermediate non-trusted DIAMETER server (also known
as a proxy server, depicted as DIA2 in the figure below) the AVP
needs to be decrypted using Shared-Secret-1 and re-encrypted by DIA2
using Shared-Secret-2.
(Shared-Secret-1) (Shared-Secret-2)
+------+ -----> +------+ ------> +------+
| | | | | |
| DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
| | | | | |
+------+ +------+ +------+
Unfortunately in this case the non-trusted server DIA2 has access to
sensitive information (such as a password).
4.7.2 AVP Encryption with Public Keys
AVP encryption using public keys is much more complex than the
previously decribed method, yet it is desirable to use it in cases
where the DIAMETER message will be processed by an untrusted
intermediate node (proxy).
Public Key encryption SHOULD be supported, however it is permissible
for a low powered device initiating the DIAMETER message to use
shared secret encryption with the first hop (proxy) DIAMETER server,
which would decrypt and encrypt using the Public Key method.
The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host
is aware of the sender's public key. This information can be relayed
in three different methods as described in section 4.3.
The AVP is encrypted in the method described in [9].
Calhoun, Rubens expires January 1999 [Page 53]
INTERNET DRAFT July 1998
4.8 Public Key Cryptography Support
A DIAMETER peer's public key is required in order to validate a
message which includes the the Digital-Signature AVP. There are three
possibilities on retrieving public keys:
4.8.1 X509-Certificate
A message which includes a Digital-Signature MAY include the X509-
Certificate AVP. Given the size of a typical certificate, this is
very wasteful and in most cases DIAMETER peers would cache such
information in order to minimize per packet processing overhead.
It is however valid for a DIAMETER host to provide its X509-
Certificate in certain cases, such as when issuing the Device-
Reboot-Indication. It is envisioned that the peer would validate and
cache the certificate at that time.
4.8.2 X509-Certificate-URL
The X509-Certificate-URL is a method for a DIAMETER host sending a
message that includes the Digital-Signature to provide a pointer to
its certificate.
Upon receiving such a message a DIAMETER host MAY choose to retrieve
the certificate if it is not locally cached. Of course the process of
retrieving and validating a certificate is lengthy and will require
the initiator of the message to retransmit the request. However once
cached the certificate can be used until it expires.
4.8.3 Static Public Key Configuration
Given that using certificates requires a PKI infrastructure which is
very costly, it is also possible to use this technology by locally
configuring DIAMETER peers' public keys.
Note that in a network involving many DIAMETER proxies this may not
scale well.
5.0 References
[1] Rigney, et alia, "RADIUS", RFC-2138, April 1997
[2] Reynolds, Postel, "Assigned Numbers", RFC 1700,
October 1994.
[3] Postel, "User Datagram Protocol", RFC 768, August 1980.
Calhoun, Rubens expires January 1999 [Page 54]
INTERNET DRAFT July 1998
[4] Rivest, Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[5] Kaufman, Perlman, Speciner, "Network Security: Private
Communications in a Public World", Prentice Hall,
March 1995, ISBN 0-13-061466-1.
[6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, January 1997.
[7] Calhoun, Bulley, "DIAMETER User Authentication Extensions",
draft-calhoun-diameter-authen-03.txt, May 1998.
[8] Aboba, Beadles, "Network Address Identifier", Internet-Draft,
draft-ietf-roamops-nai-10.txt, February 1998.
[9] Kaliski, "PKCS #1: RSA Encryption Version 1.5", Internet-
Draft, draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997.
[10] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-
Draft, draft-calhoun-diameter-framework-00.txt, May 1998
[11] Zorn, Leifer, Rubens, Shriver, "RADIUS attributes for
Tunnel Protocol Support", Internet-Draft,
draft-ietf-radius-tunnel-auth-05.txt, April 1998.
6.0 Acknowledgements
The Authors would like to acknowledge the following people for their
contribution in the development of the DIAMETER protocol:
Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant,
Nancy Greene, Peter Heitman, Ryan Moats, Victor Muslin, Kenneth
Peirce, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn
The authors would also like to thanks the authors of the L2TP spec
since most of the windowing text in this draft was shamefully copied
from that spec.
7.0 Author's Address
Questions about this memo can be directed to:
Pat R. Calhoun
Technology Development
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pcalhoun@eng.sun.com
Calhoun, Rubens expires January 1999 [Page 55]
INTERNET DRAFT July 1998
Allan C. Rubens
Ascend Communications
1678 Broadway
Ann Arbor, MI 48105-1812
USA
Phone: 1-734-761-6025
E-Mail: acr@del.com
Calhoun, Rubens expires January 1999 [Page 56]
INTERNET DRAFT July 1998
Appendix A: Acknowledgment Timeouts
DIAMETER uses sliding windows and timeouts to provide flow-control
across the underlying medium and to perform efficient data buffering
to keep two DIAMETER peers' receive window full without causing
receive buffer overflow. DIAMETER requires that a timeout be used to
recover from dropped packets.
When the timeout for a peer expires, the previously transmitted
message with Ns value equal to the highest in-sequence value of Nr
received from the peer is retransmitted. The receiving peer does not
advance its value for the receive sequence number state, Sr, until it
receives a message with Ns equal to its current value of Sr.
This rule assues that all sunsequent acknowledgements to this peer
will contain an Nr value equal to the Ns value of the first missing
message until a message with the missing Ns value is received.
The exact implementation of the acknowledgment timeout is vendor-
specific. It is suggested that an adaptive timeout be implemented
with backoff for flow control. The timeout mechanism proposed here
has the following properties:
Independent timeouts for each peer. A device will have to
maintain and calculate timeouts for every active peer.
An administrator-adjustable maximum timeout, MaxTimeOut, unique to
each device.
An adaptive timeout mechanism that compensates for changing
throughput. To reduce packet processing overhead, vendors may
choose not to recompute the adaptive timeout for every received
acknowledgment. The result of this overhead reduction is that the
timeout will not respond as quickly to rapid network changes.
Timer backoff on timeout to reduce congestion. The backed-off
timer value is limited by the configurable maximum timeout value.
Timer backoff is done every time an acknowledgment timeout occurs.
In general, this mechanism has the desirable behavior of quickly
backing off upon a timeout and of slowly decreasing the timeout
value as packets are delivered without timeouts.
A.1 Calculating Adaptive Acknowledgment Timeout
We still must decide how much time to allow for acknowledgments to
return. If the timeout is set too high, we may wait an unnecessarily
Calhoun, Rubens expires January 1999 [Page 57]
INTERNET DRAFT July 1998
long time for dropped packets. If the timeout is too short, we may
time out just before the acknowledgment arrives. The acknowledgment
timeout should also be reasonable and responsive to changing network
conditions.
The suggested adaptive algorithm detailed below is based on the TCP
1989 implementation and is explained in Richard Steven's book TCP/IP
Illustrated, Volume 1 (page 300). 'n' means this iteration of the
calculation, and 'n-1' refers to values from the last calculation.
DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta *
(|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n])
ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)
DIFF represents the error between the last estimated round-trip
time and the measured time. DIFF is calculated on each iteration.
DEV is the estimated mean deviation. This approximates the
standard deviation. DEV is calculated on each iteration and
stored for use in the next iteration. Initially, it is set to 0.
RTT is the estimated round-trip time of an average packet. RTT is
calculated on each iteration and stored for use in the next
iteration. Initially, it is set to PPD.
ATO is the adaptive timeout for the next transmitted packet. ATO
is calculated on each iteration. Its value is limited, by the MIN
function, to be a maximum of the configured MaxTimeOut value.
Alpha is the gain for the round trip estimate error and is
typically 1/8 (0.125).
Beta is the gain for the deviation and is typically 1/4 (0.250).
Chi is the gain for the timeout and is typically set to 4.
To eliminate division operations for fractional gain elements, the
entire set of equations can be scaled. With the suggested gain
constants, they should be scaled by 8 to eliminate all division. To
simplify calculations, all gain values are kept to powers of two so
that shift operations can be used in place of multiplication or
division. The above calculations are carried out each time an
acknowledgment is received for a packet that was not retransmitted
(no timeout occurs).
A.2 Flow Control: Adjusting for Timeout
Calhoun, Rubens expires January 1999 [Page 58]
INTERNET DRAFT July 1998
This section describes how the calculation of ATO is modified in the
case where a timeout does occur. When a timeout occurs, the timeout
value should be adjusted rapidly upward. Although L2TP payload
packets are not retransmitted when a timeout occurs, the timeout
should be adjusted up toward a maximum limit. To compensate for
shifting internetwork time delays, a strategy must be employed to
increase the timeout when it expires. A simple formula called Karn's
Algorithm is used in TCP implementations and may be used in
implementing the backoff timers for the LNS or the LAC. Notice that
in addition to increasing the timeout, we also shrink the size of the
window as described in the next section.
Karn's timer backoff algorithm, as used in TCP, is:
NewTIMEOUT = delta * TIMEOUT
Adapted to our timeout calculations, for an interval in which a
timeout occurs, the new timeout interval ATO is calculated as:
RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MIN (RTT[n] +
(chi * DEV[n]), MaxTimeOut)
In this modified calculation of ATO, only the two values that
contribute to ATO and that are stored for the next iteration are
calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is
not carried forward and is not used in this scenario. A value of 2
for Delta, the timeout gain factor for RTT, is suggested.
Appendix B: Examples of sequence numbering
Although sequence numbers serve distinct purposes for control and
data messages, both types of messages use identical techniques for
assigning sequence numbers. This appendix shows several common
scenarios, and illustrates how sequence number state progresses and
is interpreted.
B.1: Lock-step tunnel establishment
in this example, a DIAMETER device establishes communication with a
peer, with the exchange involving each side alternating in sending
messages. This example is contrived, in that the final
acknowledgement in the example is typically the acknowledgement would
have been included in the processing of the Device-Watchdog-Ind.
DIAMETER Host A DIAMETER Host B
-> Device-Reboot-Ind
Nr: 0, Ns: 0
Calhoun, Rubens expires January 1999 [Page 59]
INTERNET DRAFT July 1998
(ZLB) <-
Nr: 1, Ns: 0
-> Device-Watchdog-Ind
Nr: 1, Ns: 1
(delay)
(ZLB) <-
Nr: 2, Ns: 1
B.2: Multiple packets acknowledged
This example shows a flow of packets from DIAMETER Host B to Host A,
with Host A having no traffic of its own. Host B is waiting 1/4 of
its timeout interval, and then acknowledging all packets seen since
the last interval.
DIAMETER Host A DIAMETER Host B
(previous packet flow precedes this)
-> (ZLB)
Nr: 7000, Ns: 1000
(non-ZLB) <-
Nr: 1000, Ns: 7000
(non-ZLB) <-
Nr: 1000, Ns: 7001
(non-ZLB) <-
Nr: 1000, Ns: 7002
(Host A's timer indicates it should acknowledge pending
traffic)
-> (ZLB)
Nr: 7003, Ns: 1000
B.3: Lost packet with retransmission
Host A attempts to communicate with Host B. The Device-Reboot-Ind is
lost and must be retransmitted by Host B.
DIAMETER Host A DIAMETER Host B
-> Device-Reboot-Ind
Nr: 0, Ns: 0
(packet lost) Device-Reboot-Ind <-
Nr: 1, Ns: 0
Calhoun, Rubens expires January 1999 [Page 60]
INTERNET DRAFT July 1998
(pause; Host A's timer started first, so fires first)
-> Device-Reboot-Ind
Nr: 0, Ns: 0
(Host B realizes it has already seen this packet)
(Host B might use this as a cue to retransmit, as in this
example)
Device-Reboot-Ind <-
Nr: 1, Ns: 0
-> Device-Watchdog-Ind
Nr: 1, Ns: 1
(delay)
(zero-length) <-
Nr: 2, Ns: 0
Calhoun, Rubens expires January 1999 [Page 61]