INTERNET DRAFT P. Tom Taylor
Nortel (Northern Telecom)
Title: draft-taylor-ipdc-00.txt Pat R. Calhoun
Date: July 1998 Sun Microsystems, Inc.
Allan C. Rubens
Ascend Communications
IPDC
Base Protocol
<draft-taylor-ipdc-00.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 protocol described in this document provides the basis for the IP
Device Control (IPDC) family of protocols. The IPDC protocols are
proposed as a protocol suite, components of which can be used
individually or together to perform connection control, media
control, and signaling transport for environments where the service
control logic is separated from the network access server. Please see
the references section for other IPDC documents.
According to the framework provided by Cuervo et al [1], the IPDC
protocol suite operates between the Media Gateway Controller and the
Media Gateway. In terms of previous contributions to the experts of
Questions 13-14/16, the corresponding entities are the Call Control
and Media Control portions of the H.323 Gateway. The operation of
IPDC in the service of H.323 is clarified in a companion contribution
Taylor, Calhoun, Rubens expires January 1999 [Page 1]
INTERNET DRAFT IPDC Base Protocol July 1998
entitled "IPDC Architectural Framework" [3].
Table of Contents
1.0 Introduction
1.1 Definitions
1.2 Terminology
2.0 Transport
2.1 Protocol Overview
3.0 Message Format
3.1 Transaction Identification
4.0 AVP Format
5.0 AVP Definitions
5.1 Command AVP
5.1.1 DIAMETER Base Commands
5.1.1.1 Command-Unrecognized-Ind
5.1.1.2 Device-Reboot-Ind
5.1.1.3 Device-Watchdog-Ind
5.1.1.4 Device-Feature-Query
5.1.1.5 Device-Feature-Reply
5.1.1.6 Device-Config-Req
5.1.1.7 Device-Config-Answer
5.1.2 Additional IPDC Commands
5.1.2.1 Command-Ack
5.1.2.2 Message-Reject
5.2 Other AVPs
5.2.1 DIAMETER Base AVPs
5.2.1.1 Host-IP-Address
5.2.1.2 Host-Name
5.2.1.3 Version-Number
5.2.1.4 Extension-Id
5.2.1.5 Integrity-Check-Vector
5.2.1.6 Digital-Signature
5.2.1.7 Initialization-Vector
5.2.1.8 Timestamp
5.2.1.9 Session-Id
5.2.1.10 X509-Certificate
5.2.1.11 X509-Certificate-URL
5.2.1.12 Vendor-Name
5.2.1.13 Firmware-Revision
5.2.1.14 Result-Code
5.2.1.15 Error-Code
5.2.1.16 Unknown-Command-Code
5.2.1.17 Reboot-Type
5.2.1.18 Reboot-Timer
5.2.1.19 Message-Timer
5.2.1.20 Message-In-Progress-Timer
Taylor, Calhoun, Rubens expires January 1999 [Page 2]
INTERNET DRAFT IPDC Base Protocol July 1998
5.2.1.21 Message-Retry-Count
5.2.1.22 Message-Forward-Count
5.2.1.23 Receive-Window
5.2.2 Additional IPDC AVPs
5.2.2.1 Transaction-Originator
5.2.2.2 Failed-AVP-Code
5.3 IPDC AVP Templates
5.3.1 IPDC Reference
6.0 Protocol Definition
6.1 Bootstrap Message
6.2 Keepalive Exchange
6.3 Unrecognized Command Support
6.4 The art of AVP Tagging
6.5 Device Configuration
6.6 Data Integrity
6.6.1 Using the Integrity-Check-Vector
6.6.2 Using Digital Signatures
6.6.3 Using Mixed Data Integrity AVPs
6.7 AVP Data Encryption
6.7.1 AVP Encryption with Shared Secrets
6.7.2 AVP Encryption with Public Keys
6.8 Public Key Cryptography Support
6.8.1 X509-Certificate
6.8.2 X509-Certificate-URL
6.8.3 Static Public Key Configuration
7.0 References
8.0 Rights and Permissions
9.0 Acknowledgements
10.0 Authors' Addresses
Appendix A: Acknowledgement Timeouts
Appendix B: Examples Of Sequence Numbering
1.0 Introduction
A need has been identified for one or more protocols to control
gateway devices which sit at the boundary between the circuit-
switched telephone network and the internet and terminate circuit-
switched trunks. Examples of such devices include network access
servers and voice-over-IP gateways. The need for a control protocol
separate from call signalling arises when the service control logic
needed to process calls lies partly or wholly outside the gateway
devices.
Cuervo et al [1] and Skran [3] describe the architectural context
within which the gateway control protocols must operate. Using the
Taylor, Calhoun, Rubens expires January 1999 [Page 3]
INTERNET DRAFT IPDC Base Protocol July 1998
terminology established by [1], the protocols implement the interface
between the Media Gateway Controller and the Media Gateway. The
present document along with documents listed in the references [4],
[5], [6], and [7] describe the IP Device Control (IPDC) protocol
suite, which is proposed for that purpose.
Note that IPDC views the Media Gateway as an application which may
control one or more physical devices. In addition to its primary
mandate, IPDC MAY be used to control devices which do not meet the
strict definition of Media Gateway such as digital cross-connects and
announcement servers.
IPDC builds on the base already provided by DIAMETER [2]. DIAMETER
has a number of advantages as a starting point:
* built-in provision for control security
* facilities for starting up the control relation
* ready extensibility both in modular increments and at the atomic
(individual command and attribute) level.
Because DIAMETER is specifically written for the AAA (authentication,
authorization, accounting) application, the authors of the IPDC
proposal have chosen to use DIAMETER 's syntactical framework rather
than DIAMETER itself. The present document looks very much like the
current DIAMETER Base document [2], but various changes to suit the
IPDC application environment have created a protocol which is
interoperable with but not identical with DIAMETER.
This document describes the base IPDC protocol. This document in
itself is not complete and MUST be used with one or more accompanying
task-specific extension documents such as those provided by [4], [5],
[6], and [7].
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.
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.
Taylor, Calhoun, Rubens expires January 1999 [Page 4]
INTERNET DRAFT IPDC Base Protocol July 1998
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 IPDC protocol consists of a message header followed by
Attribute-Value-Pairs (AVPs). An AVP is a data object
encapsulated in a header.
Command
An IPDC command is a specialized data object which indicates the
purpose and structure of the message containing it. Because of
this identification between command type and message format, the
command name may be used denote the message format, as, for
example, "IPDC-Alive Message".
DIAMETER Device
A Diameter device is a client or server system that supports the
Diameter Base protocol and 0 or more extensions.
Integrity Check Vector
An Integrity Check Vector is a hash of the packet with a shared
secret.
IPDC Entity
An IPDC entity is any object, logical or physical, which is
subject to control through IPDC or whose status IPDC must report.
Every IPDC entity has a type. The complete list of IPDC entity
types is provided as part of the definition of the IPDC Reference
AVP template in section 5.3.1.
IPDC Protocol Endpoint
The term IPDC protocol endpoint is used to refer to either of the
two parties to an IPDC control session: the Media Gateway
Controller or the Media Gateway. To the extent that IPDC may be
viewed as providing extensions to DIAMETER, an IPDC protocol
endpoint is also a Diameter device.
Transaction
A transaction is sequence of messages pre-defined as part of the
definition of the IPDC commands which constitute that sequence.
Every message in the sequence carries the same Identifier value in
the header and same Transaction-Originator value identifying the
originator of the transaction, as described in Section 3.1.
Taylor, Calhoun, Rubens expires January 1999 [Page 5]
INTERNET DRAFT IPDC Base Protocol July 1998
2.0 Transport
DIAMETER packets MAY be transmitted over UDP or TCP. Each DIAMETER
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.
IPDC requires a reliable, order-preserving transport protocol with
minimal latency so that IPDC control is responsive to the demands of
call processing. UDP combined with the protocol description in the
next section satisfies these requirements, and is therefore the
default transport protocol for IPDC. Network operators MAY choose to
implement TCP instead for greater security or other reasons.
2.1 Protocol Overview
There are two different types of IPDC/DIAMETER messages: header-only
messages and messages containing Attribute-Value Pairs (AVPs) in
addition to headers. Header-only messages are used for explicitly
acknowledging packets to the peer.
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.
It is imperative that no two outstanding requests from an
IPDC/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 values are unique
across reboots, as long as the IPDC/DIAMETER node issues a Device-
Reboot-Ind message after reboot completion.
A IPDC/ DIAMETER implementation SHOULD keep transmitted requests in a
queue until a response with the same Identifier value is received in
order to ensure that it can match the request with the response
received.
Two additional fields in the IPDC/ DIAMETER header are important to
the operation of the protocol: the Nr (Next Received) and Ns (Next
Send) values. A single sequence number state is maintained for all
IPDC/ DIAMETER messages to a given peer. The Sequence number starts
at 0 upon startup of the control session. Each subsequent packet is
sent with the next increment of the sequence number.
The sequence number is thus a free running counter represented modulo
Taylor, Calhoun, Rubens expires January 1999 [Page 6]
INTERNET DRAFT IPDC Base Protocol July 1998
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. In a message sent before any
message is received Nr will be 0, indicating that the peer expects
the next new Ns value to be 0.
When an AVP-containing 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 expected message.
Every time a peer sends an AVP-containing 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 header-only message indicates that the message 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 header-only message sent after an AVP-containing message will
contain the new Ns value while the AVP-containing message sent after
a header-only message with contain the same value of Ns as the
preceding header-only message.
Upon receipt of an in-order AVP-containing 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
Taylor, Calhoun, Rubens expires January 1999 [Page 7]
INTERNET DRAFT IPDC Base Protocol July 1998
value can be piggybacked in the Nr field of any AVP-containing
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 an AVP-containing message then it should send a
header-only 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 header-
only 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 an AVP-containing 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 header-only ACK is issued. If they are equal, then no
ACK's are outstanding and no action needs to be taken.
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 B for some examples of how sequence numbers progress.
3.0 Header Format
A summary of the IPDC message format is shown below. The fields are
transmitted from left to right. This format is identical to that
proposed for DIAMETER [2].
Taylor, Calhoun, Rubens expires January 1999 [Page 8]
INTERNET DRAFT IPDC Base Protocol 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RADIUS PCC |PKT Flags| Ver | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Send (Ns) | Next Received (Nr) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
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/IPDC messages from RADIUS a special value has been
reserved and allows an implementation to support both protocols
concurrently using the first octet in the header. The RADIUS PCC
field MUST be set as follows:
254 DIAMETER/IPDC message
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 IPDC Version 1.
Packet Length
The Packet Length field is two octets. It indicates the length of
the message including the header fields; thus message AVP content
MUST NOT exceed 65,528 octets. 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.
Taylor, Calhoun, Rubens expires January 1999 [Page 9]
INTERNET DRAFT IPDC Base Protocol July 1998
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 contains any AVPs.
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
highest (modulo 2^16) in-sequence message received. See section
2.0 for more information.
Attributes
See section 4.0 for more information on attribute formats. The
end of the list of attributes is defined by the length of the
message minus the length of the header.
3.1 Transaction Identification
In addition to the use of the transaction Identifier field of the
message header described above, all implementations of IPDC MUST
include an instance of Transaction-Originator AVP in each message.
This AVP MUST identify the originator of the transaction to which the
current message belongs. In other words, as well as assigning the
value of the Identifier, the IPDC protocol endpoint initiating a
transaction records its identity by means of a Transaction-Originator
AVP. All subsequent messages in that transaction MUST copy the
original Identifier and Transaction-Originator values.
The intent is that the combination of Identifier and Transaction-
Originator provides a unique transaction identifier over the set of
all such identifiers outstanding at a given moment of time over the
complete network. This is necessary because IPDC is designed to
allow transactions to survive the specific control sessions in which
they originated. It is possible, for example, that when a Media
Gateway Controller fails a new Media Gateway Controller acting as a
hot stand-by to the failed unit takes over the outstanding
transactions from the IPDC control session which was terminated by
the failure. The new Media Gateway Controller may have other
outstanding transactions, whose identifiers must not be duplicated by
those of the transactions from the failed unit.
Taylor, Calhoun, Rubens expires January 1999 [Page 10]
INTERNET DRAFT IPDC Base Protocol July 1998
4.0 AVP Format
IPDC Attributes carry the specific commands and parameters which must
be exchanged between IPDC protocol endpoints to perform the tasks
associated with Media Gateway control. IPDC attributes may be viewed
as a class of DIAMETER attributes, since the AVPs have the same
header format.
Some DIAMETER Attributes MAY be listed more than once. The effect of
this is command specific, and is specified by each such attribute
description. IPDC avoids this condition as a matter of design
philosophy.
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
AVPs of string and data type be padded accordingly. The padding size
can be deduced using the following formula:
padding_size = (4 - (Length modulo 4)) modulo 4
A summary of the attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (opt) | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
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 [8]. Each extension MUST allocate AVP numbers
through the IANA. AVP numbers between 1000 and 1999 are used for
IPDC.
If the Vendor-Specific-AVP flag is set, the AVP Code is allocated
from the vendor's private address space, with one exception. The
AVP Code 256 is reserved for commands in all address spaces. See
the documentation of the Command AVP in section 5.1 for
interpretation of that AVP when the Vendor-Specific-AVP flag is
Taylor, Calhoun, Rubens expires January 1999 [Page 11]
INTERNET DRAFT IPDC Base Protocol July 1998
set.
AVP Length
The AVP Length field is two octets, and indicates the length of
this Attribute including the AVP Code, AVP Length, Reserved, AVP
Flags, Vendor ID if present and the attribute value field. If a
message is received with an invalid attribute length, the message
SHOULD be rejected.
In AVP descriptions, the indicated length corresponds to the AVP
format as illustrated, which in general excludes the length of the
Tag field, the Vendor ID in the header, and other vendor-specific
information.
Reserved
The Reserved field MUST be set to zero (0) in all AVPs.
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 6.6 for more
information.
When the 'E' bit is enabled it indicates that the AVP data is
encrypted using end-to-end encryption. See section 6.6 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 space, with the sole exception of AVP Code 256 -
Command AVP. This AVP Code code is reserved in all address
spaces. See the description of the Command AVP in section 5.1
for more details.
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.
Taylor, Calhoun, Rubens expires January 1999 [Page 12]
INTERNET DRAFT IPDC Base Protocol July 1998
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.
Unless otherwise specified in the description of specific AVPs,
IPDC imposes the following constraints on the values of the AVP
Flags:
* the 'M' bit MUST be set
* the 'H', 'E', and 'P' bits MAY be set
* the 'V' bit MAY be set
* the 'T' bit MUST NOT be set.
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. Vendors wishing to implement IPDC
extensions can use their own Vendor IDs 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 and MUST
NOT be used in an AVP since it is implied with the absence of the
Vendor-Specific-AVP bit.
Tag
The Tag field is optional; its presence is signalled by setting
the 'T' AVP Flag bit. It contains a 16-bit value which is the
same for all AVPs in the same tag group. Tag groups are used to
distinguish sets of related AVPs within a single message, where
otherwise these relationships would be ambiguous. Thus the value
of the tag for a given tag group must be unique over all tags used
within the same message. See section 6.4 for more information on
the use of tags. The use of tagging is command dependent and must
be specified as part of the description of any command that
requires such use.
Value
The Value field is zero or more octets and contains information
specific to the Attribute. The format and length of the Value
field is determined by the AVP Code and AVP Length fields.
The format of the Value field MAY be one of six primitive data
types. It is also possible for the Value field to have a
structure, which MUST be defined along with the attribute. The
type of the Value field is implicit in the AVP description, not
coded explicitly. The primitive types are:
Taylor, Calhoun, Rubens expires January 1999 [Page 13]
INTERNET DRAFT IPDC Base Protocol July 1998
Data
0-65520 octets of arbitrary data.
String
0-65520 octets of string data using the UTF-8 character set.
Address
32 bit network address, most significant octet first, or 48 bit
transport address, network address part first, most significant
octet first for each of the network address and port
respectively. The choice between network and transport
address is indicated by the AVP length. This specification of
the address data type amplifies that given in the DIAMETER
specification [2], but is believed to capture its intent.
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.
5.0 AVP Definitions
IPDC Base attributes include those inherited from DIAMETER [2] and
those added specifically for IPDC. Because of its special role in
defining message purpose and format, the Command AVP and the commands
contained in DIAMETER/IPDC Base are documented separately from other
attributes. Section 5.1 describes the Command AVP, while subsections
of section 5.1 describe the individual commands. Section 5.2
describes the other attributes contained in DIAMETER/IPDC Base.
5.1 Command AVP
Description
The Command AVP MUST be the first AVP following the message header.
This AVP is used to communicate the purpose and structure of 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taylor, Calhoun, Rubens expires January 1999 [Page 14]
INTERNET DRAFT IPDC Base Protocol July 1998
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional data depending on the specific command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 Command. The AVP Code value 256 is reserved to denote an
Command AVP even if the Vendor-Specific-AVP bit is set. However,
in that case the interpretation of the Command Code and any
additional content in the value field is vendor-specific.
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 Vendor-Specific-AVP bit MUST be set if and only if the command
is vendor-specific.
Command Code
The Command Code field contains the command number. IPDC command
numbers are taken from the range 1000-1999.
5.1.1 DIAMETER Base Commands
Definitions for the following commands are copied from [2] and MUST
be supported by all DIAMETER implementations in order to conform to
the DIAMETER base protocol specification. IPDC requires, in
contradiction to DIAMETER, that IPDC implementations use the IPDC
command Message-Reject instead of the DIAMETER command Command-
Unrecognized-Ind. Note that Message-Reject has greater scope than
Command-Unrecognized-Ind.
Command Name Command Code
Command-Unrecognized-Ind 256
Device-Reboot-Ind 257
Device-Watchdog-Ind 258
Device-Feature-Query 259
Device-Feature-Reply 260
Device-Config-Request 304
Taylor, Calhoun, Rubens expires January 1999 [Page 15]
INTERNET DRAFT IPDC Base Protocol July 1998
Device-Config-Answer 305
5.1.1.1 Command-Unrecognized-Ind (CUI)
Description
This description appears as a matter of record only: it applies to
DIAMETER devices other than IPDC protocol endpoints. IPDC protocol
endpoints MUST use the Message-Reject command with appropriate return
code instead of the Command-Unrecognized-Ind command.
Messages with the Command-Unrecognized-Ind 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-Ind message.
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 }
A summary of the Command-Unrecognized-Ind packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
Taylor, Calhoun, Rubens expires January 1999 [Page 16]
INTERNET DRAFT IPDC Base Protocol July 1998
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The flag field MUST have bit one (Mandatory Support) set.
Command Code
The Command Code field MUST be set to 256 (Command-Unrecognized-
Ind).
5.1.1.2 Device-Reboot-Indication (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 its 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 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 desirable for a DIAMETER device to retain the supported
extensions as well as the version number 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.
Taylor, Calhoun, Rubens expires January 1999 [Page 17]
INTERNET DRAFT IPDC Base Protocol July 1998
In the case where a IPDC/DIAMETER device such as the Media Gateway
Controller 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>
<Transaction-Originator 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 }
In the case where a DIAMETER device is configured to communicate with
many peers, this message MUST be issued to each peer. For IPDC, this
applies in particular to a recovering Media Gateway Controller.
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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
Taylor, Calhoun, Rubens expires January 1999 [Page 18]
INTERNET DRAFT IPDC Base Protocol July 1998
As per IPDC defaults.
Command Code
The Command Code field MUST be set to 257 (Device-Reboot-
Indication).
5.1.1.3 Device-Watchdog-Ind (WDI)
Description
Device-Watchdog-Ind is used as a keepalive mechanism between two
DIAMETER peers. When UDP is used as the transport layer, this message
alone is not sufficient to detect loss of connectivity at the
application level; it must be supplemented with the use of the
message sequence number mechanisms described in section 2.1. See
examples of the use of Device-Watchdog-Ind in Appendix B.
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>
<Transaction-Originator 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taylor, Calhoun, Rubens expires January 1999 [Page 19]
INTERNET DRAFT IPDC Base Protocol July 1998
AVP Code
256 Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Command Code
The Command Code field MUST be set to 258 (Device-Watchdog-Ind).
5.1.1.4 Device-Feature-Query (DFQ)
Description
The Device-Feature-Query message is used in order to query a peer
about its 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>
<Transaction-Originator AVP>
[<Version-Number>]
[<Vendor-Name>]
[<Extension-Id>]
<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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 Command
Taylor, Calhoun, Rubens expires January 1999 [Page 20]
INTERNET DRAFT IPDC Base Protocol July 1998
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Command Code
The Command Code field MUST be set to 259 (Device-Feature-Query).
5.1.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 extensions supported
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>
<Transaction-Originator AVP>
[<Version-Number>]
[<Vendor-Name>]
<Extension-Id>
<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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 Command
AVP Length
Taylor, Calhoun, Rubens expires January 1999 [Page 21]
INTERNET DRAFT IPDC Base Protocol July 1998
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Command Code
The Command Code field MUST be set to 260 (Device-Feature-
Response).
5.1.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.
IPDC implementations MUST include the Transaction-Originator AVP as
specified in section 3.1. IPDC implementations MAY include the
Session-ID AVP.
Message Format
<Device-Config-Request> ::= <DIAMETER Header>
<Device-Config-Request Command AVP>
<Transaction-Originator 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
Taylor, Calhoun, Rubens expires January 1999 [Page 22]
INTERNET DRAFT IPDC Base Protocol 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Command Code
The Command Code field MUST be set to 304 (Device-Config-Request).
5.1.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.
IPDC implementations MUST include the Transaction-Originator AVP as
specified in section 3.1. IPDC implementations MAY include the
Session-ID AVP.
Message Format
<Device-Config-Answer> ::= <DIAMETER Header>
<Device-Config-Answer Command AVP>
<Transaction-Originator AVP>
<Session-Id AVP>
Taylor, Calhoun, Rubens expires January 1999 [Page 23]
INTERNET DRAFT IPDC Base Protocol July 1998
<Result-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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Command Code
The Command Code field MUST be set to 305 (Device-Config-Answer).
5.1.2 Additional IPDC Commands
The following commands are defined in this draft and MUST be
supported by all IPDC implementations:
Command Name Command Code
Command-Ack 1100
Message-Reject 1101
Taylor, Calhoun, Rubens expires January 1999 [Page 24]
INTERNET DRAFT IPDC Base Protocol July 1998
5.1.2.1 Command-Ack (ACK)
Description
The Command-Ack command provides a generic means of completing
transactions by acknowledging the messages which initiated them.
The documentation for each transaction-initiating IPDC command MUST
indicate if the expected response to that command is Command-Ack or
some more specialized command type. The structure of the Command-Ack
message is defined as follows:
<Command-Ack message> ::=
<Message Header>
<Command AVP>
<Transaction-Originator AVP>
where the Identifier value in the message header and the
Transaction-Originator AVP are copied from the message being
acknowledged and the Command AVP has the following 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 Command
AVP Length
The length of this attribute MUST be at exactly 12.
AVP Flags
As per IPDC defaults.
Command Code
1100 Command-Ack
5.1.2.3 Message-Reject (MRJ)
Description
The Message-Reject command provides a generic means of completing
Taylor, Calhoun, Rubens expires January 1999 [Page 25]
INTERNET DRAFT IPDC Base Protocol July 1998
transactions by indicating errors in the messages which initiated
them. The Message-Reject command is a possible response to any IPDC
command, but some IPDC commands MAY expect more specialized error
messages, depending on the error type.
The Message-Reject message MUST contain the same transaction
identification (header Identifier field, Transaction-Originator
value) as the message it is responding to, even if that
identification is erroneous. The receiver of a Message-Reject SHOULD
examine the Result-Code value it provides before processing the
transaction identification, in order to handle the latter
appropriately.
The structure of the Message-Reject message is defined as follows:
<Message-Reject message> ::=
<Message Header>
<Command AVP>
<Transaction-Originator AVP>
<Result-Code AVP>
[ <Error-Code AVP> ]
[ <Failed-AVP-Code AVP> ]
[ <Unknown-Command-Code AVP> ]
where the Identifier value in the message header and the
Transaction-Originator AVP are copied from the message being rejected
and the Command AVP has the format described below. The Result-Code
and conditionally-present Error-Code AVPs indicate the nature of the
error causing rejection, and the conditionally-present Failed-AVP-
Code AVP provides some minimal debugging data by indicating a
specific AVP type which caused the problem. See the description of
the Result-Code AVP in section 5.2.1.14 for indication of when the
Error-Code and/or Failed-AVP-Code AVPs will be present in the
message. The Unknown-Command-Code AVP is present only when the
reason for message rejection is an unrecognized or unsupported
command code.
The documentation of individual IPDC commands MAY also include
documentation of the expected contents of an ensuing Message-Reject
message, beyond the information given in section 5.2.1.14.
The format of the Command AVP for Message-Reject 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taylor, Calhoun, Rubens expires January 1999 [Page 26]
INTERNET DRAFT IPDC Base Protocol July 1998
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 Command
AVP Length
The length of this attribute MUST be at exactly 12.
AVP Flags
As per IPDC defaults.
Command Code
1101 Message-Reject
5.2 Other AVPs
This section defines the IPDC Base attributes other than the Command
AVP. A number of these attributes are inherited from DIAMETER Base
[2]; these are documented in section 5.2.1. IPDC adds some
additional attributes, documented in section 5.2.2.
5.2.1 DIAMETER Base AVPs
Aside from the Command AVP, DIAMETER Base [2] defines the following
AVPs:
Attribute Name Attribute Code
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
Taylor, Calhoun, Rubens expires January 1999 [Page 27]
INTERNET DRAFT IPDC Base Protocol July 1998
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
Message-Forward-Count 276
Receive-Window 277
5.2.1.1 Host-IP-Address
Description
The Host-IP-Address attribute is used to inform a DIAMETER peer of
the sender's identity.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
4 Host-IP-Address
AVP Length
The length of this attribute MUST be at least 12.
AVP Flags
As per IPDC defaults.
Address
The Address field is of type Address and contains the sender's IP
address.
5.2.1.2 Host-Name
Description
The Host-Name attribute is used to inform a DIAMETER peer of the
sender's identity.
Taylor, Calhoun, Rubens expires January 1999 [Page 28]
INTERNET DRAFT IPDC Base Protocol 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
AVP Code
32 Host-Name
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
As per IPDC defaults.
Name
The Name field is of type String. It consists of one or more
octets, and should be unique to the DIAMETER host. The Host Name
MUST follow the NAI [12] naming conventions.
5.2.1.3 Version-Number
Description
[Whether IPDC has its own version numbering independently of DIAMETER
is for future determination.] The Version-Number AVP is used in
order to indicate the current DIAMETER system version number to a
peer. It has the following 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
257 Version-Number
AVP Length
Taylor, Calhoun, Rubens expires January 1999 [Page 29]
INTERNET DRAFT IPDC Base Protocol July 1998
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Version
Version is of type Integer32, and contains the system's DIAMETER
version number.
5.2.1.4 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-Response command in order to inform the peer what
extensions are locally supported.
Each DIAMETER extensions draft MUST have a Extension-Id assigned to
it by the IANA. The base protocol does not require an Extension-Id
since its support is mandatory. [Whether IPDC Base and the IPDC
extensions described in [4], [5], [6], and [7] are registered as
DIAMETER extensions or establish an extension system of their own is
for future determination.]
There MAY be more than one Extension-Id AVP within a DIAMETER
message.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
258 Extension-Id
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Taylor, Calhoun, Rubens expires January 1999 [Page 30]
INTERNET DRAFT IPDC Base Protocol July 1998
Extension Number
The Extension Number is of type Integer32, and contains the
extension identifier as defined in the extension's document.
5.2.1.5 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 message header as well as all AVPs up to and including
the 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 by
the method described in section 6.6.1.
All DIAMETER/IPDC implementations MUST support this AVP.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Check Value ...
+-+-+-+-+-+-+-+-+
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', and 'P' bits MUST NOT be
set.
Transform ID
The Transform ID field is of type Integer32 and identifies the
algorithm used to generate the check value. The following values
are defined in this document:
1 HMAC-MD5-96 [6]
Taylor, Calhoun, Rubens expires January 1999 [Page 31]
INTERNET DRAFT IPDC Base Protocol July 1998
Check Value
The Check Value field is of type Data and contains an integrity
check value for the message up to this AVP.
5.2.1.6 Digital-Signature
Description
The Digital-Signature AVP is used for authentication and 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, which 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 'P' bit disabled are
protected by the Digital-Signature.
Note that for services which use the concept of a proxy server which
forwards the request to a next hop server, the proxy server MUST NOT
modify any attributes found prior to the Digital- Signature AVP. This
ensures that end-to-end security is maintained even through proxy
arrangements.
The Digital-Signature is generated by the method described in section
6.6.2.
All DIAMETER implementations SHOULD support this AVP. [Requirements
for IPDC implementations are for future determination.]
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature ...
+-+-+-+-+-+-+-+-+
AVP Code
260 Digital-Signature
Taylor, Calhoun, Rubens expires January 1999 [Page 32]
INTERNET DRAFT IPDC Base Protocol July 1998
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
The 'M' bit MUST be set. The 'H' MAY be set if the request is
protected with an ICV AVP. The 'E'and 'P' bits MUST NOT be set.
Address
The Address field is of type Address and contains the IP address
of the IPDC host which generated the Digital-Signature.
Transform ID
The Transform ID field is of type Integer32 and identifies the
algorithm used to generate the Signature value. The following
values are defined in this document:
1 RSA [9]
Signature
The Signature field is of type Data and contains the digital
signature of the packet up to this AVP.
5.2.1.7 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.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+ Random +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taylor, Calhoun, Rubens expires January 1999 [Page 33]
INTERNET DRAFT IPDC Base Protocol July 1998
AVP Code
261 Initialization-Vector
AVP Length
The length of this attribute MUST be 24.
AVP Flags
As per IPDC defaults.
Random
The Random field is of type Data and contains a random 128-bit
value.
5.2.1.8 Timestamp
Description
The Timestamp field is used in order to enable protection against
replay 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 within which an
implementation will accept packets; however, it is strongly
encouraged that this value be made user configurable with a
reasonable default value (e.g. 4 seconds).
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
262 Timestamp
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Timestamp
Taylor, Calhoun, Rubens expires January 1999 [Page 34]
INTERNET DRAFT IPDC Base Protocol July 1998
The Timestamp field is of type Time and contains the time at which
the message was created.
5.2.1.9 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 follows:
<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 the client.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SessionId ...
+-+-+-+-+-+-+-+-+
AVP Code
263 Session-Id
AVP Length
Taylor, Calhoun, Rubens expires January 1999 [Page 35]
INTERNET DRAFT IPDC Base Protocol July 1998
The length of this attribute MUST be at least 12.
AVP Flags
As per IPDC defaults.
SessionId
The SessionId field is of type Data and contains the session
identifier assigned to the session.
5.2.1.10 X509-Certificate
Description
The X509-Certificate is used to send a DIAMETER peer the local
system's X.509 certificate chain, which is used to validate the
Digital-Signature attribute.
Section 6.8 contains more information about the use of certificates.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chain ...
+-+-+-+-+-+-+-+-+
AVP Code
264 X509-Certificate
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
As per IPDC defaults.
Chain
The Chain field is of type Data and contains the X.509 Certificate
Chain.
5.2.1.11 X509-Certificate-URL
Description
Taylor, Calhoun, Rubens expires January 1999 [Page 36]
INTERNET DRAFT IPDC Base Protocol July 1998
The X509-Certificate-URL is used to send a DIAMETER peer a URL
pointing to the local system's X.509 certificate chain, which is used
in order to validate the Digital-Signature attribute.
Section 6.8 contains more information about the use of certificates.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URL ...
+-+-+-+-+-+-+-+-+
AVP Code
265 X509-Certificate-URL
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
As per IPDC defaults.
URL
The URL field is of type String and contains the X.509 Certificate
Chain URL.
5.2.1.12 Vendor-Name
Description
The Vendor-Name attribute is used to tell a DIAMETER peer the Vendor
Name of the DIAMETER device. This MAY be used by the peer to decide
which vendor specific attributes may be sent to this DIAMETER device.
It is also envisioned that the combination of the Vendor-Name and the
Firmware-Revision AVPs can provide very useful debugging information.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
Taylor, Calhoun, Rubens expires January 1999 [Page 37]
INTERNET DRAFT IPDC Base Protocol July 1998
+-+-+-+-+-+-+-+-+
AVP Code
266 Vendor-Name
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
As per IPDC defaults.
Name
The Name field is of type String and contains the vendor name.
5.2.1.13 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.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revision Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
267 Firmware-Revision
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Revision Code
The Revision Code field is of type Integer32 and contains the
firmware revision number of the issuing device.
Taylor, Calhoun, Rubens expires January 1999 [Page 38]
INTERNET DRAFT IPDC Base Protocol July 1998
5.2.1.14 Result-Code
Description
The Result-Code AVP is used to indicate whether a particular command
was completed successfully or whether an error occurred. All
DIAMETER/IPDC commands MUST specify whether the Result-Code AVP MUST
be present.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
268 Result-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Result Code
The Result Code field is of type Integer32 and contains the result
code associated with the DIAMETER or IPDC command. The following
codes have been defined:
DIAMETER_SUCCESS 0
The Request was successfully completed. IPDC responses MAY
contain this Result Code value, but typically positive IPDC
responses will be conveyed by the Command-Ack message.
DIAMETER_FAILURE 1
The Request was not successfully completed for an unspecified
reason. An IPDC Message-Reject message returning this result
SHOULD whenever possible also contain one or more Failed-AVP-
Code AVPs indicating the attributes which caused the failure.
DIAMETER_POOR_REQUEST 2
The Request was poorly constructed. An IPDC Message-Reject
message returning this result SHOULD whenever possible also
contain one or more Failed-AVP-Code AVPs indicating the
Taylor, Calhoun, Rubens expires January 1999 [Page 39]
INTERNET DRAFT IPDC Base Protocol July 1998
attributes which caused the failure.
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. The message MUST also contain an Error-Code
AVP which provides command-specific information on the failure.
An IPDC Message-Reject message returning this result SHOULD
whenever possible also contain one or more Failed-AVP-Code AVPs
indicating the attributes which caused the failure.
IPDC_COMMAND_UNSUPPORTED 6
The Request contained a command code which the IPDC
implementation does not recognize or does not support. IPDC
implementations MUST return a Message-Reject message containing
this Result Code value rather than use the DIAMETER Command-
Unrecognized message. The Message-Reject message MUST also
contain an Unknown-Command-Code AVP which contains the Command
Code value which was rejected.
IPDC_BAD_TRANSACTION_ID 7
The Request contained invalid transaction identification.
Possible errors include a missing Transaction-Originator AVP,
an unrecognized IPDC protocol endpoint identifier in the
Transaction-Originator AVP or an Identifier value in the
message header of a response which is not recognized as
pertaining to a currently outstanding transaction at the
receiving IPDC protocol endpoint.
IPDC_ATTRIBUTE_UNSUPPORTED 8
The Request contained an AVP with an AVP Code which the IPDC
implementation does not recognize or does not support. An IPDC
Message-Reject message returning this result MUST also contain
one or more Failed-AVP-Code AVPs indicating the AVP Codes which
caused the failure.
5.2.1.15 Error-Code
Description
The Error-Code AVP contains the message-specific error code, if any.
This AVP MUST be present if and only if the Result-Code AVP is
Taylor, Calhoun, Rubens expires January 1999 [Page 40]
INTERNET DRAFT IPDC Base Protocol July 1998
present containing the value DIAMETER_SEE_ERROR_CODE. IPDC error
responses, particularly Message-Reject, MAY contain more than one
Error-Code AVP, each possibly paired with a Failed-AVP-Code AVP.
Error-Code values and corresponding semantics are specific to the
command to which the Error-Code is a response, and MUST therefore be
documented as part of the description of that command.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
268 Error-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Error Code
The Error Code field is of type Integer32 and contains the error
code value.
5.2.1.16 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taylor, Calhoun, Rubens expires January 1999 [Page 41]
INTERNET DRAFT IPDC Base Protocol July 1998
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
270 Unknown-Command-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Command Code
The Command Code field is of type Integer32 field and contains the
unrecognized command code that resulted
5.2.1.17 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reboot Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
271 Reboot-Type
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Reboot Type
The Reboot Type field is of type Integer32 and contains the reboot
type associated with the DRI command. The following values are
Taylor, Calhoun, Rubens expires January 1999 [Page 42]
INTERNET DRAFT IPDC Base Protocol July 1998
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 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.
5.2.1.18 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Estimated Outage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
272 Reboot-Time
AVP Length
The length of this attribute MUST be 12.
AVP Flags
Taylor, Calhoun, Rubens expires January 1999 [Page 43]
INTERNET DRAFT IPDC Base Protocol July 1998
As per IPDC defaults.
Estimated Outage
The Estimated Outage field is of type Integer32 and contains the
expected amount of seconds before the issuer of the DRI expects to
be able to receive new DIAMETER messages.
5.2.1.19 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
273 Message-Timer
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Retry Time
The Retry Time field is of type Integer32 and contains the value
of the retry timer in milliseconds. A value of 0 for this timer
means that the device's default value for this timer is to be
used.
Taylor, Calhoun, Rubens expires January 1999 [Page 44]
INTERNET DRAFT IPDC Base Protocol July 1998
5.2.1.20 Message-In-Progress-Timer
Description
This AVP is used by a device's state machine to deterimine how long
to wait before sending a Message-In-Progress message that tells the
peer device that the message for which it is expecting a response or
acknowledgment 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wait time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
274 Message-In-Progress-Timer
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Wait Time
The Wait Time field is of type Integer32 and contains the value of
the timer in milliseconds. A value of 0 indicates that the
MessageInProgress-Indication message is not being used.
5.2.1.21 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 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
Taylor, Calhoun, Rubens expires January 1999 [Page 45]
INTERNET DRAFT IPDC Base Protocol July 1998
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Resends |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
275 Message-Retry-Count
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Max Resends
The Max Resends field is of type Integer32 and contains the
maximum allowed retry count for a given message.
5.2.1.22 Maximum-Forward-Count
Description
This AVP is used by a device to determine if a message shouldcontinue
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Forwards |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
276 Maximum-Forward-Count
AVP Length
The length of this attribute MUST be 12.
Taylor, Calhoun, Rubens expires January 1999 [Page 46]
INTERNET DRAFT IPDC Base Protocol July 1998
AVP Flags
As per IPDC defaults.
Max Forwards
This field is of type Integer32 and contains the limit on the
number of times the message should be forwarded beyond the current
node.
5.2.1.23 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 messages 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
277 Receive-Window
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Window
This field is of type Integer32 and contains the receive window
size.
5.2.2 Additional IPDC AVPs
The attributes defined in this section MUST be supported by all IPDC
implementations.
Taylor, Calhoun, Rubens expires January 1999 [Page 47]
INTERNET DRAFT IPDC Base Protocol July 1998
5.2.2.1 Transaction-Originator
Description
As described in section 3.1, every IPDC message must contain an
instance of the Transaction-Originator AVP. The Transaction-
Originator AVP contains information which uniquely identifies the
IPDC protocol endpoint which originated a transaction. The
uniqueness MUST be broad enough in scope to permit transactions
originated in one control session to be continued in another control
session where one of the endpoints has been replaced after failure.
In particular, it is required in order to support takeover of the
transaction by an alternate Media Gateway Controller.
The Transaction-Originator AVP has the following 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Id ...
+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1000 Transaction-Originator
AVP Length
The length of this attribute MUST be at least 9.
AVP Flags
As per IPDC defaults.
Originator Id
The Originator Id field is of type Data and contains information
of arbitrary format which uniquely identifies an IPDC protocol
endpoint within the network. Typically this information, combined
with the value of the Identifier field in the message header,
provides an index into the list of outstanding transactions at the
originating IPDC protocol endpoint.
5.2.2.2 Failed-AVP-Code
Description
Taylor, Calhoun, Rubens expires January 1999 [Page 48]
INTERNET DRAFT IPDC Base Protocol July 1998
The Failed-AVP-Code AVP provides debugging information in cases where
a request is rejected or not fully processed due to erroneous
information in a specific AVP. The documentation of the Return-Code
AVP in section 5.2.1.14 and of the Message-Reject command in section
provide information on the use of the Failed-AVP-Code AVP. This AVP
has the following 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
1001 Failed-AVP-Code
AVP Length
The length of this attribute MUST be 12.
AVP Flags
As per IPDC defaults.
Failed AVP Code
The Failed AVP Code field is of type Integer32 and contains the
AVP Code value of an AVP which could not be processed
successfully. Possible reasons for this are an improperly-
constructed AVP, an unsupported or unrecognized AVP Code, or an
invalid value.
Note that where more than one instance of the same AVP Code was
present in the message to which the one containing the Failed-
AVP-Code AVP is a response, the value of the AVP Code is
insufficient to uniquely identify the actual AVP causing the
problem.
5.3 IPDC AVP Templates
The IPDC design philosophy values semantic precision over re-
usability of AVP types. Thus the same AVP structure may appear
repeatedly, but associated with different AVP Codes. IPDC avoids
dependence on AVP sequence within a message to convey meaning.
Taylor, Calhoun, Rubens expires January 1999 [Page 49]
INTERNET DRAFT IPDC Base Protocol July 1998
This design approach has the advantage that it promotes stateless
decoding of IPDC messages, although it requires the IPDC
encoder/decoder to have a broader repertoire of AVP Codes than the
alternative. From the documentation point of view, its main
disadvantage is the extra space taken up in documentation of AVP
structures. To minimize that disadvantage, IPDC introduces the
concept of AVP templates. These are descriptions of frequently-
occuring AVP structures to which other IPDC protocol documentation
may refer. This draft defines one such template: the IPDC Reference.
5.3.1 IPDC Reference
5.3.1.1 Description
The IPDC-Reference attribute provides a generic means of referring to
the objects of IPDC control. The format of the IPDC-Reference 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 |P|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entity Type Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Entity Name ...
+-+-+-+-+-+-+-+-+-+-+-
AVP Code
Assigned in the specific AVP definition which refers to this
template.
AVP Length
The length of this attribute MUST be at least 12.
AVP Flags
As per IPDC defaults.
Entity Type Code
The Entity Type Code field is of type Integer32 and indicates the
entity type denoted by this AVP. The following Entity Type Codes
have been defined:
MEDIA_GATEWAY 0
The Media Gateway application which forms one endpoint of an
IPDC control session.
Taylor, Calhoun, Rubens expires January 1999 [Page 50]
INTERNET DRAFT IPDC Base Protocol July 1998
PHYSICAL_GATEWAY 1
A physical gateway unit.
STATION 2
A degenerate case of a physical gateway unit serving only a
single access termination.
EQUIPMENT_HOLDER 3
A physical container of other gateway resources such as a shelf
or card.
TRANSPORT_TERMINATION 4
The physical termination at a gateway of an analogue or digital
transmission link such as a DS-1, either from the circuit-
switched network or from the packet network.
ACCESS_TERMINATION 5
The logical termination at a gateway of a bearer connection
(and associated signalling if not on a separate channel) from
an user device.
TRUNK_TERMINATION 6
The logical termination at a gateway of a bearer connection
(and associated signalling if not on a separate channel) from a
circuit switch.
SIGNALLING_TERMINATION 7
The logical termination at a gateway of a call signalling
channel (e.g. ISDN D-channel) from a circuit switch or user
device.
DEVICE 8
An internal physical unit of a type not otherwise covered by
this list of entity types.
MODEM 9
A modem internal to a gateway.
CONFERENCE_PORT 10
A port on a conference bridge internal to a gateway.
FAX_PORT 11
An internal endpoint capable of accepting and forwarding bearer
content consisting of encoded facsimile.
STREAM_SOURCE 12
An internal source of bearer content such as an announcement or
tone, meant to be transmitted to an user.
Taylor, Calhoun, Rubens expires January 1999 [Page 51]
INTERNET DRAFT IPDC Base Protocol July 1998
STREAM_RECORDER 13
An internal recording destination for bearer content coming
from an user, such as a voice mailbox.
RTP_PORT 14
A pair of transport addresses respectively defining the remote
and local termination points of a bi-directional RTP-
encapsulated media stream. See the naming rules for this
entity in the next section for the means by which uni-
directional streams are represented.
ATM_SPEC 15
An address specification suitable for establishing an ATM
connection. Details for further study.
H323_SPEC 16
A call signalling transport address specification or equivalent
such as an H.323 alias, suitable for establishing an outgoing
H.323 signalling connection.
SIP_SPEC 17
An address specification suitable for establishing a SIP
signalling connection.
Entity Name
The Entity Name field is of type String and specifies the
particular entity or set of entities to which the command applies.
The next section specifies and gives examples of the possible form
of the naming string for each of the entity types listed above.
Provision is made for wild-carding operations on a given set of
entities. The Entity Name field MAY be present for the
MEDIA_GATEWAY entity, but MUST be present for all other types.
5.3.1.2 Naming of IPDC Entities
Resource Names
For all gateway resource entity types (that is, PHYSICAL_GATEWAY
through STREAM_RECORDER in the above list), naming is essentially a
matter of local convention. However, the entity name for each of
these types is naturally hierarchical, beginning with a term which
identifies the physical gateway containing the given resource and
ending in a term which specifies the individual resource concerned.
With this in mind, the following rules for construction and
interpretation of the Entity Name field for these entity types MUST
be supported:
Taylor, Calhoun, Rubens expires January 1999 [Page 52]
INTERNET DRAFT IPDC Base Protocol July 1998
1. The individual terms of the naming path MUST be separated by
a single slash ("/", ASCII 2F hex).
2. Optionally, the first term MAY be of the form:
FORM:<formname>
where <formname> is a string defined by local agreement which implies
a specific form and semantic interpretation of the remaining terms of
the naming path. This is necessary to support multiple
representations of a single reference type. For example, a reference
that specifies a trunk termination may take multiple vendor dependent
formats. The substring "FORM:" is reserved for this purpose at the
start of the naming string.
3. Wild-carding is represented either by an asterisk ("*") or a
dollar sign ("$") for the terms of the naming path which are to be
wild-carded. Thus, if the full naming path looks like
term1/term2/term3
then the Entity Name field looks like this depending on which terms
are wild-carded:
*/term2/term3 if term1 is wild-carded
term1/*/term3 if term2 is wild-carded
term1/term2/* if term3 is wild-carded
term1/*/* if term2 and term3 are wild-carded,
etc.
In each of these examples a dollar sign could have appeared instead
of an asterisk.
4. A term represented by an asterisk is to be interpreted as:
"use ALL values of this term known within the scope of the Media
Gateway". A term represented by a dollar sign is to be interpreted
as: "use ANY ONE value of this term known within the scope of the
Media Gateway". The description of a specific command or AVP may add
further criteria for selection within the general rules given here.
5. If the Media Gateway controls multiple physical gateways, the
first term of the naming string beyond the optional FORM: term MUST
identify the physical gateway containing the desired entity. If the
Media Gateway controls only a single physical gateway, the first term
of the naming string MAY identify that physical gateway, depending on
local practice.
Taylor, Calhoun, Rubens expires January 1999 [Page 53]
INTERNET DRAFT IPDC Base Protocol July 1998
RTP Ports
The basic format of the RTP entity name consists of three terms
separated by slashes ("/", ASCII 2F hex) which together define a
two-way RTP connection from the point of view of one physical
endpoint. The first term identifies a physical gateway, the second
is the transport address to which an RTP-encapsulated media stream is
transmitted from that gateway, and the third is the transport address
at which the gateway receives an RTP-encapsulated media stream.
The first term MUST be present if the Media Gateway application
controls more than one physical gateway. However, this term and the
slash which separates it from the first transport address are
optional if the Media Gateway application controls only a single
physical gateway.
The two transport addresses each have the form:
<network address> : <port number>
The representation of each address is in ASCII text rather than
binary, to facilitate the representation of uni-directional flows.
If one of the flows is not required/not present, the term
representing that flow MUST consist of the minus ("-") character
alone.
Wildcarding of the network address and/or port number for either
term is permitted, using the wildcard characters and their meanings
as defined above. Typically the $ wild-card will be used, as when
the Media Gateway Controller leaves it up to the Media Gateway itself
to select an available port for an RTP connection (and report it back
to the Media Gateway Controller). Examples of wildcarded RTP entity
names are shown in the next section.
Other Address Types
The formats for representing the ATM, H323_SPEC, and SIP_SPEC types
follow from already-defined standards.
ATM
For further study.
H.323
As defined in ITU-T Recommendation H.225.0, the far end call
Taylor, Calhoun, Rubens expires January 1999 [Page 54]
INTERNET DRAFT IPDC Base Protocol July 1998
signalling address which an H.323 endpoint uses to start up a new
H.323 call can have the following forms:
* E.164 number
* H.323 ID - an arbitrary Unicode string (maximum 256 characters)
* a URL (maximum 512 ASCII characters)
* an explicit transport address
* an RFC822-compliant E-mail address (maximum 512 ASCII
characters)
* a {number type, number} structure (the PartyNumber structure),
where the number type is private or public with several
subdivisions within each of these broad categories.
H.323 actually allows for multiple addresses which could be used as
alternatives to start the call or to set up n x 64 kbit/s
connections, but these possibilities are beyond the scope of the IPDC
Reference for the H323-SPEC entity type.
An IPDC implementation MUST represent the above possibilities within
the Entity Name as follows:
1. An E.164 number, a URL, and an RFC822-compliant E-mail
address MUST be represented in their native format, as ASCII strings.
2. A transport address MUST be represented in ASCII text in the
form:
<network address> : <port number>
3. An H.323 ID MUST be represented according to the Unicode
specification (ISO/IEC 10646-1).
4. The {number type, number} structure MUST be represented by a
combination of three ASCII strings separated by slashes ("/"). The
first two strings convey the type of number, while the third consists
of the digits of the actual number. The mapping between type of
number and the representation in the IPDC Reference is as follows:
* the first term consists of one of the two non-case-sensitive
keywords PUBLIC or PRIVATE, as applicable.
* for PUBLIC numbers, the second term consists of one of the
following non-case-sensitive keywords as applicable:
- UNKNOWN
If used, number digits carry prefix indicating type of
number according to national recommendations.
- INTERNATIONAL
- NATIONAL
- SUBSCRIBER
- ABBREVIATED
Valid only for called party number at the outgoing access,
Taylor, Calhoun, Rubens expires January 1999 [Page 55]
INTERNET DRAFT IPDC Base Protocol July 1998
switched circuit network substitutes appropriate number.
* for PRIVATE numbers, the second term consists of one of these
non-case-sensitive keywords as applicable:
- UNKNOWN
- Level2Regional
- Level1Regional
- pISNSpecific
- LocalNumber
- AbbreviatedNumber.
SIP-SPEC
The contents of the Entity Name field for a SIP_SPEC entity consist
of the address specification required to start up a SIP session.
5.3.1.3 Example Entity Name values for each reference type
MEDIA_GATEWAY
The optional entity name could be descriptive (e.g. "OtwaNASCtl")
or simply a serial number (e.g. "061452").
PHYSICAL_GATEWAY
As for the MEDIA_GATEWAY, except that the entity name MUST be
present if the Media Gateway application controls more than one
physical gateway. Examples: "OtwaNAS1", "061452-1".
STATION
As for the MEDIA_GATEWAY, except that the entity name MUST be
present if the Media Gateway application controls more than one
physical gateway/station. It is likely that STATION naming will
be numeric because of the large potential number of stations
within the span of control of a single Media Gateway application.
EQUIPMENT_HOLDER
Here the FORM: specification might come into play. For example,
consider a card on a shelf within a physical gateway bay, and
suppose that the card terminates multiple transmission facilities.
Then the card is an entity of type EQUIPMENT_HOLDER, as is the
shelf which contains it.
One natural naming scheme would identify the shelf and card as
individual terms of the naming string:
Taylor, Calhoun, Rubens expires January 1999 [Page 56]
INTERNET DRAFT IPDC Base Protocol July 1998
"OtwaNAS1/3/17",
meaning shelf 3, card 17 in physical gateway OtwaNAS1.
On the other hand, in accordance with the BMLC form specification
described below, the same entity might be named
"FORM:BMLC/OtwaNAS1/3-17",
since the "M" part of "BMLC" allows for one EQUIPMENT_HOLDER term
only.
In both of the examples, the gateway identifier term could be
absent if the Media Gateway controls only one physical gateway.
The examples then become:
"3/17"
and
"FORM:BMLC/3-17"
respectively.
Finally, individual terms MAY be wild-carded. For example, using
the first naming convention, one could refer to all cards on shelf
3 using the Entity Name
"3/*"
with the EQUIPMENT_HOLDER type. In the BMLC form, this is not
possible, but one could refer to all EQUIPMENT_HOLDER entities in
the physical gateway using the string
"FORM:BMLC/*"
with the EQUIPMENT_HOLDER type.
TRANSPORT_TERMINATION
The naming of an entity of type Transport-Termination is a natural
extension of the naming of the EQUIPMENT_HOLDER entity which
supports it. Using the above example, DS-1 port 1 on card 17 of
shelf 3 could have the following names:
"OtwaNAS1/3/17/1"
"3/17/1"
The BMLC form convention has an explicit term (the "L" part) for
the transmission facility name, so, using the previous example,
the same facility could have the names:
"FORM:BMLC/OtwaNAS1/3-17/1"
"FORM:BMLC/3-17/1"
Again, wild-carding is possible. For example, the Entity Name
values
"OtwaNAS1/*/*/*"
or
"*/*/*/*"
in the first instance, or
Taylor, Calhoun, Rubens expires January 1999 [Page 57]
INTERNET DRAFT IPDC Base Protocol July 1998
"FORM:BMLC/OtwaNAS1/*/*"
or
"FORM:BMLC/*/*"
in the second instance refer along with the TRANSPORT_TERMINATION
type code to all transmission terminations on the gateway.
ACCESS_TERMINATION
The ACCESS_TERMINATION name will be similar to that for the
TRANSPORT_TERMINATION.
TRUNK_TERMINATION
The TRUNK_TERMINATION entity type specifies a single GSTN channel
or a grouping of GSTN channels. Depending upon the type of
circuit that is connected into the gateway and the physical
architecture of the gateway, this entity type might have many
vendor defined representations. To provide one possibility for
common use, this draft suggests the "BMLC" format specification
for trunk identification. The general form of a BMLC trunk
identifier is given by:
FORM:BMLC/[<Bay identifier>]/<Module identifier>/<Line
identifier>/<Channel identifier>
Within this format, the FORM: part of the reference specifies the
"BMLC" format. This form type indicates that the channels within
a media gateway may be identified using a hierarchical structure
of bay, module, line and channel. This hierarchical structure
defines the following components:
* "channel" is a single GSTN channel. In most trunk types this
refers to a 64kb channel.
* "line" identifies the TRANSPORT_TERMINATION over which the
channel is being delivered. In most pieces of equipment this
will represent the physical interface that terminates a T1 or
T3.
* "module" identifies a logical grouping of lines, an entity of
type EQUIPMENT_HOLDER. In some pieces of equipment this may
represent a circuit board that is plugged into the backplane
and terminates multiple physical interfaces. In other pieces
of equipment it may represent a shelf of line cards.
* "bay" identifies the physical gateway that is being
controlled by the control channel over which this message is
being transmitted. The PHYSICAL_GATEWAY term MUST be omitted
Taylor, Calhoun, Rubens expires January 1999 [Page 58]
INTERNET DRAFT IPDC Base Protocol July 1998
if the Media Gateway application controls only one physical
gateway.
Example uses of the trunk-term reference type using the BMLC
format would be:
"FORM:BMLC/module2/line4/channel21"
"FORM:BMLC/2/4/21"
"FORM:BMLC/2/4/$", indicating any one channel on module 2,
line 4
"FORM:BMLC/2/*/*", indicating all channels on all facilities
supported by module 2
"FORM:BMLC/*/*/*", indicating all channels on the gateway
"FORM:BMLC/OtwaNAS01/*/*/*", indicating all channels on the
specific physical gateway OtwaNAS01, where the Media Gateway
handles more than one physical gateway.
SIGNALLING_TERMINATION
Naming of a SIGNALLING_TERMINATION entity is similar to that for a
TRUNK_TERMINATION.
DEVICE
MODEM
CONFERENCE_PORT
FAX_PORT
STREAM_SOURCE
STREAM_RECORDER
Naming conventions for these entities may be similar to those for
the TRANSPORT_TERMINATION, or may omit the EQUIPMENT_HOLDER term.
Examples of such conventions:
[<gateway name> /] <Modem group> / <Modem number>
e.g " OtwaNAS01/21/6" for modem group 21, unit 6 on OtwaNAS01.
[<gateway name> /] <Conference bridge> / <Conference port>
e.g. "4/$" refers to any one port on bridge 4 on the single
physical gateway handled by the Media Gateway application.
[<gateway name> /] <Announcement name>
e.g. "AnnSrv1/MailPrompt" refers to the MailPrompt announcement on
Announcement Server AnnSrv1, which is a physical gateway from the
point of view of the IPDC control session.
Taylor, Calhoun, Rubens expires January 1999 [Page 59]
INTERNET DRAFT IPDC Base Protocol July 1998
RTP_PORT
Examples of RTP_PORT entity names would be:
"OtwaVGW01/134.37.42.2:3003/134.37.32.5:3006"
which denotes a bi-directional media stream transmitted from
physical gateway OtwaVGW01 to port 134.37.42.2:3003, and
transmitted from the far end to port 134.37.32.5:3006 on
OtwaVGW01.
"134.37.42.2:3003/134.37.32.5:$"
which demonstrates wildcarding of the port number for the incoming
media stream.
"134.37.42.2:3003/-"
which denotes a one-way outgoing media stream.
ATM_SPEC
For further study.
H323_SPEC
Examples of H323_SPEC entity names would be:
"134.37.42.2:"
which denotes the well-known call signalling port for H.323 at the
given remote address.
"Tom Taylor"
which denotes an H.323 alias
"16137654167"
which denotes an E.164 address.
SIP_SPEC
Examples to come.
6.0 Protocol Definition
This section will describe how the base protocol works (or is at
least an attempt to do so).
6.1 DIAMETER Bootstrap Message
Taylor, Calhoun, Rubens expires January 1999 [Page 60]
INTERNET DRAFT IPDC Base Protocol July 1998
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
will be restarted.
The DIAMETER Reboot-Ind message does not require a reply. The message
is acknowledged using DIAMETER's reliable transport.
6.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.
An IPDC/DIAMETER Client can use this mechanism to ensure that
failover to an alternate server occurs even without any control
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.
6.3 Unrecognized Command Support
The DIAMETER protocol provides a message that is used to inform a
Taylor, Calhoun, Rubens expires January 1999 [Page 61]
INTERNET DRAFT IPDC Base Protocol July 1998
peer that a DIAMETER message was received with an unrecognized
command. Suppose the following message 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. A non-IPDC application will then send 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> ||
<Digital-Signature AVP }
An IPDC application will instead send the response:
<Message-Reject> ::= <DIAMETER Header>
<Message-Reject Command AVP>
<Unrecognized-Command-Code AVP>
<Transaction-Originator AVP>
<Result-Code AVP>
<Unrecognized-Command-Code AVP>
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
where the Result-Code AVP contains the Result Code value 6,
IPDC_COMMAND_UNSUPPORTED.
6.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
Taylor, Calhoun, Rubens expires January 1999 [Page 62]
INTERNET DRAFT IPDC Base Protocol July 1998
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.
6.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 or 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 at 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.
6.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
Taylor, Calhoun, Rubens expires January 1999 [Page 63]
INTERNET DRAFT IPDC Base Protocol July 1998
randomness.
6.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 desirable to use this
mechanism in the case where asymmetric 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 hash [11] of the
message up to the ICV AVP. Using the example code provided in [11],
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 includes hop-by-hop
security:
<DIAMETER Message> ::= <DIAMETER Header>
<Command AVP>
[<Additional AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
<Integrity-Check-Vector AVP>
6.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
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-
Taylor, Calhoun, Rubens expires January 1999 [Page 64]
INTERNET DRAFT IPDC Base Protocol July 1998
trusted DIA2 proxy server. If DIA2 needs to add or change any mutable
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) for purposes of 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 includes end-to-end
security:
<DIAMETER Message> ::= <DIAMETER Header>
<Command AVP>
[<Additional AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
<Digital-Signature AVP>
Note that Digital Signatures only protect the DIAMETER header and the
AVPs found prior to the digital signature. It is therefore possible
to have AVPs which are unprotected because they follow the digital
signature.
The Data field of the Digital-Signature AVP contains the RSA/MD5
signature algorithm as defined in [13].
6.6.3 Using Mixed Data Integrity AVPs
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>
Taylor, Calhoun, Rubens expires January 1999 [Page 65]
INTERNET DRAFT IPDC Base Protocol July 1998
----------------------------->
<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 appears 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.
<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
Taylor, Calhoun, Rubens expires January 1999 [Page 66]
INTERNET DRAFT IPDC Base Protocol July 1998
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.
6.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.
6.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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Taylor, Calhoun, Rubens expires January 1999 [Page 67]
INTERNET DRAFT IPDC Base Protocol July 1998
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
octets 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.
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 [14].
Please note that in the case where the DIAMETER message needs to be
processed by an intermediate non-trusted DIAMETER server (also known
Taylor, Calhoun, Rubens expires January 1999 [Page 68]
INTERNET DRAFT IPDC Base Protocol July 1998
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).
6.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
or 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 6.8.
The AVP is encrypted in the method described in [13].
6.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: transmission of the X.509
certificate itself,transmission of a URL pointing to the actual X.509
certificate, and static public key configuration. These
possibilities are discussed in the next two sections.
6.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
Taylor, Calhoun, Rubens expires January 1999 [Page 69]
INTERNET DRAFT IPDC Base Protocol July 1998
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 a message that
includes the X509-Certificate-URL 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.
6.8.2 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.
7.0 References
[1] Cuervo et alia, "SS7-Internet Interworking - Architectural
Framework", draft-greene-ss7-arch-frame-00.txt, July 1998.
[2] Calhoun, Rubens, "DIAMETER Base Protocol", draft-calhoun-
diameter-04.txt, July 1998.
[3] Skran, "IPDC Architectural Framework", draft-skran-IPDC-
frame-00.txt, August 1998.
[4] Dugan, "IPDC Connection Control", draft-dugan-IPDC-conn-
00.txt, August 1998.
[5] Elliott, "IPDC Media Control", draft-elliott-IPDC-media-
00.txt, August 1998.
[6] Bell, "IPDC Signaling Support", draft-bell-IPDC-sig-00.txt,
August 1998.
[7] Pickett, "IPDC Device Management", draft-pickett-IPDC-mgmt-
00.txt, August 1998.
[8] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1995.
[9] Rivest, Dusse, "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
Taylor, Calhoun, Rubens expires January 1999 [Page 70]
INTERNET DRAFT IPDC Base Protocol July 1998
[10] Kaufman, Perlman, Speciner, "Network Security: Private
Communications in a Public World", Prentice Hall, March 1995, ISBN
0-13-061466-1.
[11] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, January 1997.
[12] Aboba, Beadles, "Network Address Identifier", Internet-Draft,
draft-ietf-roamops-nai-11.txt, July 1998.
[13] Kaliski, "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March
1998.
[14] Rigney, et alia, "RADIUS", RFC 2138, April 1997
[15] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-Draft,
draft-calhoun-DIAMETER-framework-00.txt, May 1998
8.0 Rights and Permissions
The contributors to this document are listed in the acknowledgement
section of this document. All contributors to this document and the
organizations we represent grant an unlimited perpetual, non-
exclusive, royalty-free, world-wide right and license to any party
under the copyrights in the contribution. This license includes the
right to copy, publish and distribute the contribution in any way,
and to prepare derivative works that are based on or incorporate all
or part of the contribution, the license to such derivative works to
be of the same scope as the license of the original contribution.
The contributors grant permission to reference the names of the
contributors and of the organizations we represent. We agree that no
information in the contribution is confidential and that the any
party may freely disclose any information in the contribution.
The contributors to this document represent that the organizations we
represent jointly own any intellectual property associated with this
document. The contributors to this document will grant any party a
perpetual, non-exclusive, royalty-free, world-wide right to
implement, use and distribute the technology or works when
implementing, using or distributing technology based upon the
specific specification.
The contributors represent that we have disclosed the existence of
any proprietary or intellectual property rights in the contribution
that are reasonably and personally known to the contributors. The
contributors do not represent that we personally know of all
Taylor, Calhoun, Rubens expires January 1999 [Page 71]
INTERNET DRAFT IPDC Base Protocol July 1998
potentially pertinent proprietary and intellectual property rights
owned or claimed by the organizations we represent (if any) or third
parties.
The contributors represent that there are no limits to the
contributors' ability to make the grants, acknowledgments and
agreements above that are reasonably and personally known to the
contributors.
9.0 Acknowledgements
The DIAMETER base protocol specification [2] was authored by Pat
Calhoun of Sun Microsystems, Inc. and Allan C. Rubens of Ascend
Communications. [2] acknowledges 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.
[2] also acknowledges a major debt to L2TP for details of the
DIAMETER protocol.
The following people contributed to the development of the IPDC
proposal and are signatories to the declaration regarding
intellectual property rights in the previous section:
Ilya Akramovich, Bob Bell, Dan Brendes, Peter Chung, John Clark,
Russ Dehlinger, Andrew Dugan, Ike Elliott, Cary Fitzgerald, Jan
Gronski, Tom Hess, Geoff Jordan, Tony Lam, Shawn Lewis, Dave
Mazik, Alan Mikhak, Pete O'Connell, Scott Pickett, Shyamal Prasad,
Eric Presworsky, Paul Richards, Dale Skran, Louise Spergel, David
Sprague, Raj Srinivasan, Tom Taylor, and Michael Thomas.
Special acknowledgement is due to Ike Elliott for the long hours he
spent moderating the meetings of the IPDC Technical Advisory
Committee.
10.0 Authors' Addresses
Questions about this memo can be directed to:
P. Tom Taylor
Nortel (Northern Telecom)
M/S 097, SKY,
Taylor, Calhoun, Rubens expires January 1999 [Page 72]
INTERNET DRAFT IPDC Base Protocol July 1998
P.O. Box 3511, Station C,
Ottawa, Ontario,
Canada
Phone: 1-613-765-4167
Fax: 1-613-765-7236
E-mail: taylor@nortel.ca
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
Allan C. Rubens
Ascend Communications
1678 Broadway
Ann Arbor, MI 48105-1812
USA
Phone: 1-734-761-6025
E-Mail: acr@del.com
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 messages.
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 subsequent 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.
Taylor, Calhoun, Rubens expires January 1999 [Page 73]
INTERNET DRAFT IPDC Base Protocol July 1998
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
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.
Taylor, Calhoun, Rubens expires January 1999 [Page 74]
INTERNET DRAFT IPDC Base Protocol July 1998
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
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 DIAMETER messages
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
Taylor, Calhoun, Rubens expires January 1999 [Page 75]
INTERNET DRAFT IPDC Base Protocol July 1998
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 session 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 which
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
(Header-only) <-
Nr: 1, Ns: 0
-> Device-Watchdog-Ind
Nr: 1, Ns: 1
(delay)
(Header-only) <-
Nr: 2, Ns: 1
Taylor, Calhoun, Rubens expires January 1999 [Page 76]
INTERNET DRAFT IPDC Base Protocol July 1998
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)
-> (Header-only)
Nr: 7000, Ns: 1000
(Message with AVPs) <-
Nr: 1000, Ns: 7000
(Message with AVPs) <-
Nr: 1000, Ns: 7001
(Message with AVPs) <-
Nr: 1000, Ns: 7002
(Host A's timer indicates it should acknowledge pending traffic)
-> (Header-only)
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
(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
Taylor, Calhoun, Rubens expires January 1999 [Page 77]
INTERNET DRAFT IPDC Base Protocol July 1998
-> Device-Watchdog-Ind
Nr: 1, Ns: 1
(delay)
(Header-only) <-
Nr: 2, Ns: 0
____________________
Taylor, Calhoun, Rubens expires January 1999 [Page 78]