INTERNET DRAFT Nancy Greene
Category: Standards Track Nortel
Title: draft-greene-diameter-devconf-00.txt Pat R. Calhoun
Date: August 1998 Sun Microsystems, Inc.
DIAMETER
Device Configuration Extensions
<draft-greene-diameter-devconf-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
This DIAMETER Extension defines commands and AVPs that are used by
two peers to exchange DIAMETER configuration information. The intent
of this draft is to minimize configuration of devices prior to
deployment.
Calhoun, Greene expires February 1999 [Page 1]
INTERNET DRAFT August 1998
Table of Contents
1.0 Introduction
1.1 Definitions
1.2 Terminology
2.0 Command Codes
2.1 Device-Config-Request (DCR)
2.2 Device-Config-Answer (DCA)
3.0 DIAMETER AVPs
3.1 Message-Timer
3.2 Message-In-Progress-Timer
3.3 Message-Retry-Count
3.4 Maximum-Forward-Count
4.0 Protocol Definition
4.1 Device Configuration
5.0 References
6.0 Acknowledgements
7.0 Author's Address
1.0 Introduction
This DIAMETER Extension defines commands and AVPs that are used by
two peers to exchange DIAMETER configuration information. The intent
of this draft is to minimize configuration of devices prior to
deployment.
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.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
Calhoun, Greene expires February 1999 [Page 2]
INTERNET DRAFT August 1998
implementation which does not include this option MUST
be prepared to interoperate with another implementation
which does include the option.
2.0 Command Codes
This document defines the following DIAMETER Commands. All DIAMETER
implementations supporting this extension MUST support all of the
following commands:
Command Name Command Code
-----------------------------------
Device-Config-Request 304
Device-Config-Answer 305
2.1 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.
Message Format
<Device-Config-Request> ::= <DIAMETER Header>
<Device-Config-Request Command AVP>
<Session-Id AVP>
[<Message-Timer>]
[<MessageInProgress-Timer>]
[<Message-Retry-Count>]
[<Maximum-Forward-Count>]
[<Extension-Id>]
[<Version-Number>]
[<Vendor-Name>]
[<Vendor-Specific AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
Calhoun, Greene expires February 1999 [Page 3]
INTERNET DRAFT August 1998
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Command Code
The Command Code field MUST be set to 304 (Device-Config-
Request).
2.2 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.
Calhoun, Greene expires February 1999 [Page 4]
INTERNET DRAFT August 1998
Message Format
<Device-Config-Answer> ::= <DIAMETER Header>
<Device-Config-Answer Command AVP>
<Session-Id AVP>
<Result-Code AVP>
[<Error-Code AVP>]
[<Message-Timer AVP>]
[<MessageInProgress-Timer AVP>]
[<Message-Retry-Count AVP>]
[<Maximum-Forward-Count AVP>]
[<Extension-Id AVP>]
[<Version-Number AVP>]
[<Vendor-Name AVP>]
[<Vendor-Specific AVPs>]
<Timestamp AVP>
<Initialization-Vector AVP>
{<Integrity-Check-Vector AVP> ||
<Digital-Signature AVP }
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
256 DIAMETER Command
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Command Code
Calhoun, Greene expires February 1999 [Page 5]
INTERNET DRAFT August 1998
The Command Code field MUST be set to 305 (Device-Config-
Answer).
3.0 DIAMETER AVPs
This section will define the mandatory AVPs which MUST be supported
by all DIAMETER implementations. Note the first 256 AVP numbers are
reserved for RADIUS compatibility.
The following AVPs are defined in this document:
Attribute Name Attribute Code
-----------------------------------
Message-Timer 273
Message-In-Progress-Timer 274
Message-Retry-Count 275
Maximum-Forward-Count 276
3.1 Message-Timer
Description
This AVP is used by a device to determine how long to wait before
trying again to send a message expecting a response or
acknowledgement. This timer value overrides any default value a
device may have.
Note that a DIAMETER extensions AVP could define another timer
that would override this one for a specific message type.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
273 Message-Timer
Calhoun, Greene expires February 1999 [Page 6]
INTERNET DRAFT August 1998
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
This field contains the value of the timer in milliseconds. A
value of 0 for this timer means that the default value for this
timer is to be used.
3.2 Message-In-Progress-Timer
Description
This AVP is used by a device's state machine to deterimine how
long to wait before sending a MessageInProgress message that tells
the peer device that the message it is expecting a response or
acknowledgment for is still in progress.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
274 Message-In-Progress-Timer
AVP Length
The length of this attribute MUST be 12.
AVP Flags
Calhoun, Greene expires February 1999 [Page 7]
INTERNET DRAFT August 1998
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
This field contains the value of the timer in milliseconds. A
value of 0 indicates that the MessageInProgress-Indication
message is not being used.
3.3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
275 Message-Retry-Count
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
This field contains the value for the counter.
Calhoun, Greene expires February 1999 [Page 8]
INTERNET DRAFT August 1998
3.4 Maximum-Forward-Count
Description
This AVP is used by a device to determine if a message should
continue to be forwarded. A use for this count would be to limit
the number of proxies used to satisfy a request.
AVP Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |U|T|V|E|H|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AVP Code
276 Maximum-Forward-Count
AVP Length
The length of this attribute MUST be 12.
AVP Flags
The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending
upon the security model used. The 'V', 'T' and the 'P' bits
MUST NOT be set.
Integer32
This field contains the value for the counter.
4.0 Protocol Definition
This section will describe how the base protocol works (or is at
least an attempt to).
4.1 Device Configuration
DIAMETER provides two messages that can be used by DIAMETER peers in
Calhoun, Greene expires February 1999 [Page 9]
INTERNET DRAFT August 1998
order to exchange certain configuration information, such as
retransmission timer values. This message MAY be sent at any time and
is not restricted to being sent at boot-up time only.
Upon receipt of the Device-Config-Request, the receiver SHOULD make
use of the configuration information provided when communicating with
the initiator of the message.
The receiver MUST acknowledge receipt of the message with a Device-
Config-Answer which may also contain some configuration information.
Note that if such configuration AVPs are present in the Device-
Config-Answer the peer cannot reply with a success of failure
Result-Code.
A preferable method for two nodes to "negotiate" configuration
information would be for both of them to issue Device-Config-
Requests. However in some applications minimizing packets over the
wire are startup time requires that the Device-Config-Answer carry
such information.
Note that both messages have a high probability of containing vendor
specific AVP which MAY be ignored. Implementations MUST assume that
that receiver does NOT support vendor specific AVPs sent.
5.0 References
[1] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft,
draft-calhoun-diameter-05.txt, May 1998.
[2] Reynolds, Postel, "Assigned Numbers", RFC 1700,
October 1994.
[3] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet-
Draft, draft-calhoun-diameter-framework-00.txt, May 1998
6.0 Acknowledgements
The Authors would like to acknowledge ...
7.0 Author's Address
Questions about this memo can be directed to:
Nancy Greene
Public Data Networks
Nortel (Northern Telecom)
PO Box 3511 Station C
Calhoun, Greene expires February 1999 [Page 10]
INTERNET DRAFT August 1998
Ottawa, Ontario K1Y 4H7
Canada
Phone: 1-613-763-9789
Fax: 1-613-763-8904
E-mail: ngreene@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
Calhoun, Greene expires February 1999 [Page 11]