WDIFF

draft-ietf-aaa-diameter-04.txt --> draft-ietf-aaa-diameter-05.txt

AAA Working Group Pat R. Calhoun
Internet-Draft Sun Microsystems, Inc.
Category: Standards Track Haseeb Akhtar
<draft-ietf-aaa-diameter-04.txt>
<draft-ietf-aaa-diameter-05.txt> Nortel Networks
Jari Arkko
Oy LM Ericsson Ab
Erik Guttman
Sun Microsystems, Inc.
Allan C. Rubens
Tut Systems, Inc.
Glen Zorn
Cisco Systems, Inc.
May
June 2001

Diameter Base Protocol

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."

The list of current Internet-Drafts can be accessed at:

http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at:

http://www.ietf.org/shadow.html.

Distribution of this memo is unlimited.

Calhoun et al. expires December 2001 [Page 1]

Internet-Draft June 2001

Abstract

The Diameter base protocol is intended to provide a AAA framework for

Calhoun et al. expires October 2001 [Page 1]

Internet-Draft May 2001
Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message
format, transport, error reporting and security services to be used
by all Diameter extensions applications and MUST be supported by all Diameter
implementations.

Calhoun et al. expires October 2001 [Page 2]

Internet-Draft May 2001

Table of Contents

1.0 Introduction
1.1 Diameter Protocol
1.2 Requirements language
1.3 Terminology
2.0 Protocol Overview
2.1 Transport
2.1.1 SCTP Guidelines
2.2 Securing Diameter Messages
2.3 Diameter Protocol Extensibility
2.3.1 Defining new AVP Values
2.3.2 Creating new AVPs
2.3.3 Creating a new Diameter extension Applications
2.3.4 Extension Application authentication procedures
2.4 Diameter Extensions Applications
2.5 Role of Diameter Agents
2.5.1 Relay Agents
2.5.2 Proxy Agents
2.5.3 Redirector Agents
2.5.4 Translation Agents
2.6 Diameter Server Discovery
2.7 Diameter Identity Encoding
3.0 Diameter Header
3.1 Command Code Definitions
3.2 Command Code ABNF specification
3.3 Diameter Command Naming Conventions
3.3.1 Request/Answer
3.3.2 Indication/Failed Indication
4.0 Diameter AVPs
4.1 AVP Header
4.2 Optional Header Elements
4.3 AVP Data Formats
4.4 Grouped AVP Values
4.4.1 Example AVP with a Grouped Data type
4.5 Diameter Base Protocol AVPs
5.0 Diameter message processing
5.1 Processing Local Messages
5.2 Message Forwarding
5.1 Origin-FQDN
5.2.1 Peer Table
5.3 Message Routing

Calhoun et al. expires December 2001 [Page 2]

Internet-Draft June 2001

5.3.1 Realm-Based Routing Table
5.3.2 Redirecting requests
5.3.3 Relaying and Proxying Requests
5.3.4 Relaying and Proxying Answers
5.3.5 Hiding Network Topology
5.4 Origin-Host AVP
5.2
5.5 Origin-Realm AVP
5.3 Destination-FQDN
5.6 Destination-Host AVP
5.7 Destination-Realm AVP
5.8 Routing AVPs
5.8.1 Route-Record AVP
5.8.2 Proxy-Info AVP
5.8.3 Proxy-Host AVP
5.8.4 Proxy-State AVP
5.9 Redirect-Host AVP
6.0 Capabilities Negotiation
6.1 Extension Application Identifiers
6.2 Device-Reboot-Ind (DRI) Command
6.2.1 Capabilities-Exchange-Request
6.3 Capabilities-Exchange-Answer
6.4 Vendor-Id AVP
6.2.2
6.5 Firmware-Revision AVP
6.2.3 Auth-Extension-Id
6.6 Auth-Application-Id AVP
6.2.4
6.7 Host-IP-Address AVP
6.2.5
6.8 Supported-Vendor-Id AVP
6.2.6
6.9 Product-Name AVP
6.2.7 Acct-Extension-Id
6.10 Acct-Application-Id AVP
6.11 Vendor-Specific-Application-Id AVP
7.0 Transport Failure Detection
7.1 Device-Watchdog-Request
7.2 Device-Watchdog-Answer
7.3 Failover/Failback Procedures
8.0 Peer State Machine

Calhoun et al. expires October 2001 [Page 3]

Internet-Draft May 2001
8.1 States
8.2 Events
8.3 Actions
8.4 The Election Process
9.0 Error Handling
9.1 End-to-End Error Handling
9.1.1 Result-Code AVP
9.1.1.1
9.1.1 Informational
9.1.1.2
9.1.2 Success
9.1.1.3
9.1.3 Protocol Errors
9.1.4 Transient Failures
9.1.1.4
9.1.5 Permanent Failures
9.1.2 Error-Message AVP
9.1.3 Error-Reporting-FQDN AVP
9.2 Hop-by-Hop Error Handling
9.2.1 Device-Status-Ind
9.2.2 DSI-Event AVP
9.2.2.1 Informational Events
9.2.2.2 Redirect Event
9.2.2.3 Transient Failure Events
9.2.2.4 Permanent Failure Events Message-Reject-Answer
9.3 Failed-AVP Error-Message AVP
9.4 Offending-AVP Error-Reporting-Host AVP
9.5 Failed-Vendor-Id Failed-AVP AVP
10.0 "User" Sessions

Calhoun et al. expires December 2001 [Page 3]

Internet-Draft June 2001

10.1 Authorization Session State Machine
10.2 Accounting Session State Machine
10.3 Session-Id AVP
10.4 Authorization-Lifetime AVP
10.5 Session-Timeout AVP
10.6 User-Name AVP
10.7 Max-Wait-Time AVP
10.8 Session Termination
10.8.1 Session-Termination-Ind
10.8.2
10.7.1 Session-Termination-Request
10.8.3
10.7.2 Session-Termination-Answer
11.0 Message Routing
11.1 Realm-Based Message Routing
11.1.1 Realm-Based Routing Table
11.2 Proxy and Redirect Server handling of requests
11.3 Redirect Server
11.3.1 Redirect-Host AVP
11.3.2 Redirect-Host-Address AVP
11.3.3 Redirect-Host-Port AVP
11.4 Proxy Server
11.4.1 Proxying Request and Indication messages
11.4.2 Proxying Answer and Failed Ind messages
11.4.3 Route-Record AVP
11.4.4 Proxy-Info AVP

Calhoun et al. expires October 2001 [Page 4]

Internet-Draft May 2001

11.4.5 Proxy-Address AVP
11.4.6 Proxy-State
10.8 Aborting a Session
10.8.1 Abort-Session-Request
10.8.2 Abort-Session-Answer
10.9 Termination-Cause AVP
11.4.7 Destination-Realm
10.10 Inferring Session Termination from Origin-State-Id
10.11 Origin-State-Id AVP
11.5 Applying Local Policies
11.6 Hiding Network Topology
11.7 Loop Detection
12.0
11.0 Accounting
12.1
11.1 Server Directed Model
12.2
11.2 Protocol Messages
12.3 Extension
11.3 Application document requirements
12.4
11.4 Fault Resilience
12.5
11.5 Accounting Records
13.0
12.0 Accounting Command-Codes
13.1
12.1 Accounting-Request (ACR) Command
13.2
12.2 Accounting-Answer (ACA) Command
13.3 Accounting-Status-Ind (ASI) Command
13.4
12.3 Accounting-Poll-Ind (API) Command
14.0
13.0 Accounting AVPs
14.1
13.1 Accounting-Record-Type AVP
14.2
13.2 Accounting-Interim-Interval AVP
14.3
13.3 Accounting-Record-Number AVP
14.4 Accounting-State AVP
14.5
13.4 Accounting-Session-Id AVP
15.0
13.5 Accounting-Multi-Session-Id AVP
14.0 AVP Occurrence Table
15.1
14.1 Base Protocol Command AVP Table
15.2
14.2 Accounting AVP Table
16.0
15.0 IANA Considerations
16.1
15.1 AVP Header
16.1.1
15.1.1 AVP Code
16.1.2
15.1.2 AVP Flags
16.2
15.2 Diameter Header
16.2.1
15.2.1 Command Codes
16.2.2
15.2.2 Message Flags
16.3 Extension
15.3 Application Identifier Values
16.4
15.4 Result-Code AVP Values
16.5 DSI-Event AVP Values
16.6 Accounting-State
15.5 Accounting-Record-Type AVP Values
16.7 Accounting-Record-Type
15.6 Termination-Cause AVP Values
16.8
15.7 Diameter TCP/SCTP Port Numbers
17.0 Open Issues
18.0
16.0 Diameter protocol related configurable parameters
19.0
17.0 Security Considerations
20.0

Calhoun et al. expires December 2001 [Page 4]

Internet-Draft June 2001

18.0 References
21.0
19.0 Acknowledgements
22.0
20.0 Authors' Addresses
23.0
21.0 Full Copyright Statement
22.0 Expiration Date
Appendix A. Diameter Service Template

Calhoun et al. expires October December 2001 [Page 5]

Internet-Draft May June 2001

1.0 Introduction

Historically, the RADIUS protocol has been used to provide AAA
services for dial-up PPP [42] and terminal server access. Over time,
routers and network access servers (NAS) have increased in complexity
and density, making the RADIUS protocol increasingly unsuitable for
use in such networks.

The Roaming Operations Working Group (ROAMOPS) has published a set of
specifications [20, 43, 44] that define how a PPP user can gain
access to the Internet without having to dial into his/her home
service provider's modem pool. This is achieved by allowing service
providers to cross-authenticate their users. Effectively, a user can
dial into any service provider's point of presence (POP) that has a
roaming agreement with his/her home Internet service provider (ISP),
the benefit being that the user does not have to incur a long
distance charge while traveling, which can sometimes be quite
expensive.

Given the number of ISPs today, ROAMOPS realized that requiring each
ISP to set up roaming agreements with all other ISPs did not scale.
Therefore, the working group defined a "broker", which acts as an
intermediate server, whose sole purpose is to set up these roaming
agreements. A collection of ISPs and a broker is called a "roaming
consortium". There are many such brokers in existence today; many
also provide settlement services for member ISPs.

The Mobile-IP Working Group has recently changed its focus to inter
administrative domain mobility, which is a requirement for cellular
carriers wishing to deploy IETF-based mobility protocols. The current
cellular carriers requirements [22, 23] are very similar to the
ROAMOPS model, with the exception that the access protocol is
Mobile-IP [45] instead of PPP.

The Diameter protocol was not designed from the ground up. Instead,
the basic RADIUS model was retained while fixing the flaws in the
RADIUS protocol itself. Diameter does not share a common protocol
data unit (PDU) with RADIUS, but does borrow sufficiently from the
protocol to ease migration.

The basic concept behind Diameter is to provide a base protocol that
can be extended in order to provide AAA services to new access
technologies. Currently, the protocol only concerns itself with
Internet access, both in the traditional PPP sense as well as taking
into account the ROAMOPS model, and Mobile-IP.

Although Diameter could be used to solve a wider set of AAA problems,
we are currently limiting the scope of the protocol in order to

Calhoun et al. expires October December 2001 [Page 6]

Internet-Draft May June 2001

ensure that the effort remains focused on satisfying the requirements
of network access. Note that a truly generic AAA protocol used by
many applications might provide functionality not provided by
Diameter. Therefore, it is imperative that the designers of new
applications understand their requirements before using Diameter.

1.1 Diameter Protocol

The Diameter protocol allows peers to exchange a variety of messages.
The base protocol provides the following facilities:

- Delivery of AVPs (attribute value pairs)
- Capabilities negotiation, as required in [20]
- Error notification
- Extensibility, through addition of new commands and AVPs, as
required in [21]

All data delivered by the protocol is in the form of an AVP. Some of
these AVP values are used by the Diameter protocol itself, while
others deliver data associated with particular applications which
employ Diameter. AVPs may be added arbitrarily to Diameter messages,
so long as the required AVPs are included and AVPs which are
explicitly excluded are not included. AVPs are used by base Diameter
protocol to support the following required features:

- Transporting of user authentication information, for the
purposes of enabling the Diameter server to authenticate the
user.
- Transporting of service specific authorization information,
between client and servers, allowing the peers to decide whether
a user's access request should be granted.
- Exchanging resource usage information, which MAY be used for
accounting purposes, capacity planning, etc.
- Proxying Relaying, proxying and Re-directing re-directing of Diameter messages through
a server hierarchy.

The Diameter base protocol provides the minimum requirements needed
for an AAA transport protocol, as required by NASREQ [21], Mobile IP
[22, 23], and ROAMOPS [20]. The base protocol is not intended to be
used by itself, and must be used with an application-specific
extension, a Diameter application, such as
Mobile IP [10]. The Diameter protocol was heavily inspired and builds
upon the tradition of the RADIUS [1] protocol. See section 2.4. for
more information on Diameter extensions. applications.

Any node can initiate a request. In that sense, Diameter is a peer to
peer protocol. In this document, a Diameter client is the device that
normally initiates a request for authentication and/or authorization

Calhoun et al. expires October December 2001 [Page 7]

Internet-Draft May June 2001

of a user. A Diameter server is the device that either forwards the
request to another Diameter server (known as a proxy), or one that
performs the actual authentication and/or authorization of the user
based on some profile. Given that the server MAY send unsolicited
messages to clients, it is possible for the server to initiate such
messages. An example of an unsolicited message would be for a request
that the client issue an accounting update.

1.2 Requirements language

In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [13].

1.3 Terminology

Accounting
The act of collecting information on resource usage for the
purpose of trend analysis, auditing, billing, or cost allocation.

Accounting record
A session record represents a summary of the resource consumption
of a user over the entire session. Accounting gateways creating
the session record may do so by processing interim accounting
events or accounting events from several

Authentication
The act of verifying the identity of an entity (subject).

Authorization
The act of determining whether a requesting entity (subject) will
be allowed access to a resource (object).

AVP
The Diameter protocol consists of a header followed by one or more
Attribute-Value-Pair (AVP). The AVP includes a header and is used
to encapsulation authentication, authorization or accounting
information.

Broker
A broker is a business term commonly used in AAA infrastructures.
A broker is either a relay, proxy or redirect server, and MAY be
operated by roaming consortiums.

Diameter Client Agent

Calhoun et al. expires October December 2001 [Page 8]

Internet-Draft May June 2001

A Diameter Agent is a host that is providing either server, relay,
proxy or redirector services.

Diameter Client
A Diameter Client is a device at the edge of the network that
performs access control. An example of a Diameter client is a
Network Access Server (NAS) or a Foreign Agent (FA).

Diameter Server Node
A Diameter server node is a device host that is not acting implements the Diameter protocol,
and acts either as a NAS Client, or FA.
Servers can be proxy, redirect, as a Proxy, Redirector, Server or home servers
Translation agent.

Diameter Server
A Diameter Server is one that handles authentication,
authorization and accounting requests for a particular realm. By
its very nature, a Diameter Server MUST support Diameter
applications in addition to the base protocol.

Downstream Server
Diameter Proxy servers identify a downstream server as one that is
providing routing services towards the Diameter client.

Home Domain
A Home Domain is the administrative domain with whom the user
maintains an account relationship.

Home Server
A
See Diameter Home Server is one that authenticates and/or authorizes
access for users of a particular realm. The same server MAY also
act as a proxy or redirect server for other realms, in which case
it is not acting as a Home Server for these realms. Server.

Interim accounting
An interim accounting message provides a snapshot of usage during
a user's session. It is typically implemented in order to provide
for partial accounting of a user's session in the event of a
device reboot or other network problem that prevents the reception
of a session summary message or session record.

Local Domain
A local domain is the administrative domain providing services to
a user. An administrative domain MAY act as a local domain for
certain users, while being a home domain for others.

Network Access Identifier
The Network Access Identifier, or NAI [3], is used in the Diameter
protocol to extract a user's identity and realm. The identity is
used to identify the user during authentication and/or
authorization, while the realm is used for message routing
purposes.

Proxy Server
A proxy server �ses the realm portion of the NAI to route Diameter
messages. Proxy servers are typically used to minimize the number
of security relationships that are required between Diameter
servers.

Realm

Calhoun et al. expires October December 2001 [Page 9]

Internet-Draft May June 2001

The string in the NAI that immediately follows the '@' character.
NAI realm names are required

Proxy
In addition to be unique, forwarding requests and are piggybacked on responses, proxies enforce
policies relating to resource usage and provisioning. This is
typically accomplished by tracking the administration state of the DNS namespace. Diameter makes NAS devices. While
proxies typically do not respond to client Requests prior to
receiving a Response from the server, they may originate Reject
messages in cases where policies are violated. As a result,
proxies need to understand the semantics of the messages passing
through them, and may not support all Diameter applications.

Realm
The string in the NAI that immediately follows the '@' character.
NAI realm names are required to be unique, and are piggybacked on
the administration of the DNS namespace. Diameter makes use of the
realm, also loosely referred to as domain, to determine whether
messages can be satisfied locally, or whether they must be
proxied.

Real-time Accounting
Real-time accounting involves the processing of information on
resource usage within a defined time window. Time constraints are
typically imposed in order to limit financial risk.

Redirect Server
A Diameter redirect server provides realm

Relay
Relays forward requests and responses based on routing-related
AVPs and domain forwarding table entries. Since relays do not
enforce policies, they do not examine or alter non-routing AVPs.
As a result, relays never originate messages, do not need to address translation,
by returning information necessary for
understand the semantics of messages or non-routing AVPs, and are
capable of handling any Diameter peers applications or message type.
Since relays make decisions based on information in routing AVPs
and domain forwarding tables they do not keep state on NAS
resource usage or conversations in progress.

Redirector
Rather than forwarding requests and responses between clients and
servers, Re-directs refer clients to servers and allow them to
communicate directly. Redirect servers are different from proxies
since they Since Re-directs do not participate sit in the routing
forwarding path, they do not alter any AVPs transitting between
client and server. Re-direct proxies do not originate messages and
are capable of handling any message type, although they may be
configured only to re-direct messages between
end Diameter nodes. of certain types, while
acting as Routing or Policy proxies for other types. As with
Routing proxies, re-directs do not keep state with respect to
conversations or NAS resources.

Roaming Relationships

Calhoun et al. expires December 2001 [Page 10]

Internet-Draft June 2001

Roaming relationships include relationships between companies and
ISPs, relationships among peer ISPs within a roaming association,
and relationships between an ISP and a roaming consortia.
Together, the set of relationships forming a path between a local
ISP's authentication proxy and the home authentication server is
known as the roaming relationship path.

Session
The Diameter protocol is session based. When an authorization
request is initially transmitted, it includes a session identifier
that is used for the duration of the session. The Session-
Identifier AVP contains the identifier and must be globally
unique. devices serving the same user.

Upstream Server
Diameter Proxy servers identify an upstream server as one that is
providing routing services towards the home server for a
particular message.

2.0 Protocol Overview

The base Diameter protocol is never used on its own. It is always
extended for a particular application. Three extensions to Diameter applications
are defined by companion documents: NASREQ [7], Mobile IP [10],
End-to-End Security [11]. These options are introduced in this
document but specified elsewhere. Additional extensions to Diameter
may applications
MAY be defined in the future (see Section 16.3).

Calhoun et al. expires October 2001 [Page 10]

Internet-Draft May 2001 15.3).

Diameter servers Clients MUST support the Base base protocol, which includes
Accounting, and
accounting. In addition, they MUST fully support each Diameter
application which is needed to implement the client's service, e.g.
NASREQ and/or Mobile IP. A Diameter Client which does not support
both NASREQ and Mobile IP, MUST be referred to as "Diameter X Client"
where X is the application which it supports, and not a "Diameter
Client."

Diameter Servers must support the base protocol, which includes
accounting. In addition, they MUST fully support each Diameter
application which is needed to implement the intended service, e.g.
NASREQ and/or Mobile IP. A Diameter Server which does not support
both NASREQ and Mobile IP extensions. IP, MUST be referred to as "Diameter X Server"
where X is the application which it supports, and not a "Diameter
Server."

Diameter
Clients Relays and Redirectors are, by definition, protocol
transparent, and MUST transparently support the Base Diameter base
protocol, including Accounting, which includes accounting, and MAY all Diameter applications.

Calhoun et al. expires December 2001 [Page 11]

Internet-Draft June 2001

Diameter Proxies MUST suppport the base protocol, which includes
accounting. in addition, they MUST fully support any other extension that would each Diameter
application which is needed to implement proxied services, e.g.
NASREQ and/or Mobile IP. A Diameter Proxy which does not support also
both NASREQ and Mobile IP, MUST be required referred to provide
service. as "Diameter X Proxy"
where X is the application which it supports, and not a "Diameter
Proxy."

The base Diameter protocol concerns itself with capabilities
negotiation, and how messages are sent and how peers may eventually
be abandoned. The base protocol also defines certain rules which
apply to all exchanges of messages between Diameter peers.

Communication between Diameter peers begins with one peer sending a
message to another Diameter peer. The set of AVPs included in the
message is determined by a particular application of or extension to
Diameter. We will refer to this as the Diameter extension. application. One AVP
that is included to reference a user's session is the Session-Id.

The initial request for authentication and/or authorization of a user
would include the Session-Id. The Session-Id is then used in all
subsequent messages to identify the user's session (see section 10.0
for more information). The communicating party may accept the
request, or reject it by returning a response an answer message with Result-Code
AVP set to indicate an error occurred. The specific behavior of the
diameter server or client receiving a request depends on the Diameter
extension
application employed.

Session state (associated with a Session-Id) MUST be freed upon
receipt of the Session-Termination-Request, Session-Termination-
Answer, expiration of authorized service time in the Session-Timeout
AVP, and according to rules established in a particular
extension/application of Diameter.

Exchanges of messages are either request/reply oriented, or in some
special cases, do not require replies. All such messages that do not
require replies have names ending with '-Ind' (short for Indication). Diameter
application.

The Diameter base protocol provides the Authorization-Lifetime AVP,
which MAY be used by extensions applications to specify the duration of a
specific authorized session.

2.1 Transport

The base Diameter protocol is run on port TBD of both TCP [27] and
SCTP [26] transport protocols (for interoperability test purposes
port 1812 will be used until IANA assigns a port to the protocol).
When used with TLS [38], The Diameter clients SHOULD protocol is run on port TBD of
both TCP and SCTP.

Diameter clients MUST support either TCP or SCTP, but while agents and
servers MUST support TCP if SCTP is
not available. future both. Future versions of this specification may mandate that MAY

Calhoun et al. expires October December 2001 [Page 11] 12]

Internet-Draft May June 2001

mandate that clients support SCTP. Diameter servers MUST support both TCP and
SCTP.

A Diameter node MAY initiate connections from any source port, but
MUST be prepared to receive connections on port TBD. Note that the
source and destination addresses used in request and replies MAY any
of a peer's valid IP addresses.

A given Diameter process SHOULD use the same port number to send all
messages to aid in identifying which process sent a given message.
More than one Diameter process MAY exist within a single host, so the
sender's port number is needed to discriminate them.

When no transport connection exists with a peer, an attempt to
connect SHOULD be periodically attempted. The This behavior is handled
via the Tc timer, whose recommended connection
interval value is 30 seconds.

2.2 Securing

2.1.1 SCTP Guidelines

The following are guidelines for Diameter Messages implementations that
support SCTP:

1. For interoperability: All Diameter messages nodes MUST be secured between peers, and both TLS
[38] and IP Security [37] are supported. prepared to
receive Diameter messages on any SCTP stream in the
association.
2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP
streams available to the association to prevent head-of-the-
line blocking.

2.2 Securing Diameter Messages

Diameter clients, such as Network Access Servers (NASes) and Foreign Agents, commonly referred to as clients,
Agents MUST support IP Security, while servers MUST Security [37], and MAY support both TLS and IP
Security. The communication between a client and server MUST use IP
Security, while communication between [38].
Diameter servers MUST use support TLS, but the administrator MAY opt to
configure IPSec instead of using TLS.

All hosts running Operating the Diameter protocol MUST have the necessary
without any security policies to ensure that unauthenticated Diameter packets are mechanism is not processed. recommended.

2.3 Diameter Protocol Extensibility

There are various ways the Diameter protocol can be extended. This
section is intended to assist protocol designers in selecting the
best method of using the Diameter protocol.

2.3.1 Defining new AVP Values

Calhoun et al. expires December 2001 [Page 13]

Internet-Draft June 2001

Defining a new AVP value is the best approach when a new application
needs to make use of an existing Diameter extension, application, but requires
that an existing AVP communicate different service-specific
information (e.g. NAS-Port-Type set to avian carriers).

When an existing AVP can be used to communicate the new information,
this approach is preferred over creating new AVPs.

Calhoun et al. expires October 2001 [Page 12]

Internet-Draft May 2001

In order to allocate a new AVP value, a request MUST be sent to IANA,
with a detailed explanation of the value. Furthermore, if the command
code on which the AVP value is to be used would require a different
set of mandatory AVPs be present, the list of AVPs must accompany the
request.

2.3.2 Creating new AVPs

New AVPs may be created when a new application requiring Diameter
support can make use of an existing Diameter extension, application, but
requires new AVPs to communicate service-specific information.

Prior to defining the AVP, the AVP type MUST be one of the types
listed in section 4.3. In the event that a logical grouping of AVPs
is necessary, and multiple "groups" are possible in a given command,
it is highly recommended that a Grouped AVP be used (see Section
4.4).

In order to create a new AVP, a request MUST be sent to IANA, with a
detailed explanation of the AVP, its type and possible values.
Furthermore, the request MUST include the commands that would make
use of the AVP.

Note that new AVPS to be used with an existing extension application MUST NOT
be defined to have the 'M'andatory bit set.

2.3.3 Creating new Diameter extensions Applications

Should a new application require Diameter support, but it cannot fit
within an existing extension application without requiring major changes to the
specification, it may be desirable to create a new Diameter
extension.
application. Major changes to an extension application include:
- Requiring a whole different set of mandatory AVPs to a command
- Requiring a command that has a different number of round trips
to satisfy a request (e.g. Extension application foo has a command that
requires one round trip, but new extension application bar has a command
that requires two round trips to complete).
- The method used to authenticate the user is drastically

Calhoun et al. expires December 2001 [Page 14]

Internet-Draft June 2001

different from any existing extension, application, and the authentication
information cannot be carried within the AVPs defined in the
extension.
application.

Note that the creation of a new extension application should be viewed as a
last resort.

New Diameter extensions applications MUST define at least one Command Code, the

Calhoun et al. expires October 2001 [Page 13]

Internet-Draft May 2001
expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also
define new AVPs. If the Diameter extension application has any accounting
requirements, it MUST also specify the AVPs that are to be present in
the Diameter Accounting messages (see section 12.3). 11.3).

When possible, a new Diameter extension application SHOULD attempt to re-use
any existing Diameter AVP, in order to reduce the possibility of
having multiple AVPs that carry similar information.

Every Diameter Extension application specification MUST have an IANA assigned
Extension
Application Identifier (see section 2.4).

2.3.4 Extension Application authentication procedures

When possible, extensions applications SHOULD be designed such that new
authentication methods MAY be added without requiring changes to the
extension.
application. This MAY require that new AVP values be assigned to
represent the new authentication transform, or any other scheme that
produces similar results. When possible, authentication frameworks,
such as Extensible Authentication Protocol [25], SHOULD be used.

2.4 Diameter Extension Application Compliance

Extension

Application Identifiers are advertised during the capabilities
exchange phase (see section 6.0). For a given extension, application, there are
two different ways of advertising support. First, advertising support
of the extension application via the Auth-Extension-Id Auth-Application-Id implies that the
sender supports all authentication and authorization command codes,
and the AVPs specified in the associated ABNFs, described in the
specification. Second, advertising support of the extension application via the
Acct-Extension-Id
Acct-Application-Id implies that the sender supports the Accounting
command codes defined in this specification, as well as the
accounting AVPs defined in the extension's application's specification.

An implementation MAY add arbitrary AVPs to any command defined in an
extension,
application, including vendor-specific AVPs. However, implementations
that add such AVPs MUST
NOT have with the Mandatory ('M') 'M' bit set. An implementation that adds
AVPs set are not specified in a command's ABNF, compliant,
and sets the AVP's Mandatory
bit MUST NOT advertise support of the extension.

An implementation MAY support both a proprietary version of an
extension by requesting an IANA extension identifier (see section
16.3), while supporting are at fault if the original extension. During peer rejects the
capabilities exchange, a Diameter node can determine whether to
exchange messages using request. If the proprietary or standard version sender of the
extension by inspecting the extensions advertised by the peer.

Calhoun et al. expires October December 2001 [Page 14] 15]

Internet-Draft May June 2001

2.5 Diameter Server Discovery

Allowing for dynamic Diameter server discovery will make

such a message wishes to provide service, it possible
for simpler and more robust deployment MUST resend the message
with the offending AVPs removed.

2.5 Role of AAA services. Diameter Agents

In order addition to
promote interoperable implementations of Diameter server discovery, client and servers, the following mechanisms are described. These are based on existing
IETF standards.

There are two cases where Diameter server discovery may be performed.
The first protocol introduces
relays, redirectors, proxies and translation gateways, each of which
is when a defined in Section 1.3. These Diameter client needs agents are useful for
several reasons:
- They can distribute administration of systems to discover a first-hop
Diameter server. The second case is when a Diameter server needs to
discover another server configurable
grouping, including the maintenance of security associations.
- They can be used for further handling concentration of requests from an number of
co-located or distributed NAS equipment sets to a Diameter
operation. In both cases, the following 'search order' is
recommended:

1. The Diameter implementation consults its list set of static
(manual) configured Diameter server locations. These will be like
user groups.
- They can do value-added processing to the requests or responses.
- They can used if for load balancing.
- A complex network will have multiple authentication sources,
they exist can sort requests and respond.

2. forward towards the correct target.

The Diameter implementation uses SLPv2 [28] to discover
Diameter services. The Diameter service template [32] is
included in Appendix A. It protocol requires that agents maintain transaction
state, which is recommended used for failover purposes. Transaction state implies
that SLPv2 security
be deployed (this requires distributing keys to SLPv2 agents.)
This upon forwarding a request, it's Hop-by-Hop identifier is discussed further in Appendix A.

SLPv2 will allow Diameter implementations saved,
the field is replaced with a locally unique identifier, which is
restored to discover its original value when the
location corresponding answer is
received. The request's state is released upon receipt of Diameter servers in the answer.
A stateless agent is one that only maintains transaction state.

The Proxy-Info AVP allows stateless agent to add local site, as well as
their characteristics. state to a
Diameter servers request, with specific
capabilities (say support for the Accounting extension) can be
requested, and only those guarantee that the same state will be discovered.

3. The Diameter implementation uses DNS to request
present in the SRV RR [33]
for answer. However, the '_diameter._sctp' and/or '_diameter._tcp' server in protocol's failover procedures
requires that agents maintain a copy of pending requests.

A stateful agent is one that maintains session state information, by
keeping track of all authorized active sessions. Each authorized
session is bound to a particular domain. The Diameter implementation service, and its state is considered
active either until it is notified otherwise, or by expiration. Each
authorized session has to know in
advance a expiration, which domain to look for an is communicated by
Diameter server in. This
could be deduced, for example, from servers via the 'realm' Authorized-Lifetime AVP.

Maintaining session state MAY be useful in a NAI that
an Diameter implementation needed to perform an Diameter
operation on.

Diameter allows AAA peers to protect the integrity and privacy
of communication as well as to perform end-point
authentication. Still, it is prudent to employ DNS Security as
a precaution when using DNS SRV RRs certain applications, such
as:
- Protocol translation (e.g. RADIUS <-> Diameter)
- Limiting resources authorized to look up the location of a particular user
- Per user or transaction auditing

A Diameter server. [34, 35, 36]

3.0 agent MAY act in a stateful manner for some requests,
while be stateless for others. A Diameter Header implementation MAY act as

Calhoun et al. expires October December 2001 [Page 15] 16]

Internet-Draft May June 2001

A summary

one type of agent for some requests, and as another type of agent for
others.

2.5.1 Relay Agents

Relay Agents are Diameter agents that accept requests and routes the
message to another Diameter header format is shown below. The fields
are transmitted agent based on information found in network byte order.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r r r r r r r r r F A I R| Ver | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop-by-Hop Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Flags
The Message Flags field is thirteen bits. The following bits are
assigned:

r(eserved) MUST be zero - this flag bit is reserved for
future use.
F(ailed Ind) - The indication message was rejected.
A(nswer) - The the
message (e.g. Destination-Realm). This routing decision is performed
using a response to a Request message.
I(ndication) - This notification does not solicit a response.
R(equest) - The message solicits an answer.

These flags MUST be set depending on list of supported domains, and known peers. This is known as
the command code used Diameter Routing Table, as is defined further in section x.x.

Relays MAY be used to aggregate requests from multiple Network Access
Servers (NASes) within a
Diameter message. This enables the type common geographical area (POP). The use of message
Relays is advantageous since it eliminates the need for NASes to be
interpreted, even if
configured with the specific command code is not recognized.

Command Type Flags Set
Indication - - - I
Request - - R -
Answer - A - -
Failed Ind F - - -

A necessary security information it would otherwise
require to communicate with Diameter node MUST NOT set these flags servers in any other combination.
A realms.
Likewise, this reduces the configuration load on Diameter node receiving a message in which these flags servers
that would otherwise be necessary when NASes are not
set appropriately MAY reject the message for this reason, added, changed or
deleted.

Relays modify Diameter messages by inserting, and removing, routing
information, but do not modify any other portion of a message.
Further, Relays inherent simplicity implies that they are stateless,
and therefore SHOULD log the event for diagnosis.

Version
This Version field NOT maintain session state, but MUST be set to 1 to indicate Diameter Version

Calhoun et al. expires October 2001 [Page 16]

Internet-Draft May 2001 maintain
transaction state.

+------+ ---------> +------+ ---------> +------+
| | 1.

Hop-by-Hop Identifier messages

The Hop-by-Hop Identifier field is four octets, and aids in
matching requests and replies. The sender MUST ensure that the
Hop-by-Hop identifier example provided in Figure 1 depicts a request or indication message issued from NAS,
which is
locally unique (to an access device, for the sender) at any given time, and MAY attempt user bob@abc.com. Prior to ensure that the number is unique across reboots. The sender of
an Answer or Failed Indication message MUST ensure that issuing
the Hop-
by-Hop Identifier field contains request, NAS performs a Diameter route lookup, using "abc.com" as
the same value key, and determines that was found in the corresponding request. The Hop-by-Hop identifier is normally
a monotonically increasing number, whose start value was randomly
generated. A message of type Answer or Failed Indication that is
received with an unknown Hop-by-Hop Identifier MUST to be discarded.

End-to-End Identifier
Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is
used by servers relayed to detect duplicate messages, and proxies MUST NOT
modify this field. The sender of a request, answer, indication or
failed indication message MUST insert DRL,
which is a locally unique value in
this field. The combination of Diameter Relay. DRL performs the Session-Id AVP same route lookup as NAS,
and this field
is used to detect duplicates. A relays the message of type Answer or failed
Indication to HMS, which is received with a previously seen End-to-End
Identifier, and is to abc.com's Home Diameter
Server. HMS identifies that the request can be locally consumed (meaning that supported (via
the
Destination-FQDN AVP contains realm), processes the local node's identity) SHOULD be
silently discarded.

Command-Code
The Command-Code field is four octets, authentication and/or authorization
request, and is used in order to
communicate the command associated replies with the message. The 32-bit
address space an answer, which is managed by IANA (see section 16.2).

Vendor-ID
In the event that the Command-Code field contains a vendor
specific command, the four octet Vendor-ID field contains the IANA
assigned "SMI Network Management Private Enterprise Codes" [2]
value. If the Command-Code field contains an IETF standard
Command, the Vendor-ID field MUST be set to zero (0).

AVPs
AVPs are a method of encapsulating information relevant routed back to the NAS
using Diameter message. See section 4. for more information on routing AVPs.

Since Relays do not perform any application level processing, they
provide relaying services for all Diameter applications, and

Calhoun et al. expires October December 2001 [Page 17]

Internet-Draft May June 2001

3.1 Command Codes

There are two different command types supported in

therefore MUST advertise the Relay Application Identifier.

2.5.2 Proxy Agents

Similarly to Relays, Proxy agents route Diameter
protocol; Request/Answer and Indication messages. Each command type
is assigned a command code, and messages using the sub-type
Diameter Routing Table. However, they differ since they modify
messages to implement policy enforcement. This requires that proxies
maintain the state of their downstream peers (e.g. request or answer,
Indication or Indication failure) access devices) to
enforce resource usage, provide admission control, and provisioning.

It is identified via important to note that although proxies MAY provide a value-add
function for NASes, they do not allow access devices to use the message flags
field
Diameter End-to-End Security application, since modifying messages
breaks end-to-end authentication.

Proxies MAY be used in call control centers or access ISPs that
provide outsourced connections, they can monitor the Diameter header.

Every Diameter message MUST contain a command code number and types
of ports in its header's
Command-Code field, which is used use, and make allocation and admission decisions
according to determine the action their configuration.

Proxies that is wish to limit resources MUST be taken for a particular message. The following Command Codes are
defined in the Diameter base protocol:

Command-Name Abbrev. Code Reference
--------------------------------------------------------
Accounting-Answer ACA 271 13.2
Accounting-Poll-Ind API 273 13.4
Accounting-Request ACR 271 13.1
Accounting-Status-Ind ASI 279 13.3
Device-Reboot-Ind DRI 257 6.2
Device-Status-Ind DSI 282 9.2.1
Device-Watchdog-Answer DWA 280 7.2
Device-Watchdog-Req DWR 280 7.1
Session-Termination-Ind STI 274 10.8.1
Session-Termination- STR 275 10.8.2
Request
Session-Termination- STA 275 10.8.3
Answer

3.2 Command Code ABNF specification

Every Command Code defined MUST include a corresponding ABNF
specification, which is used to define the AVPs that MUST, MAY stateful, and all
Proxies MUST maintain transaction state.

Proxy agents MUST NOT allow end-to-end security to be present. The following format is used established
between two peers if it expects to modify ANY non-routing AVP in
messages exchanged between the definition:

command-def = command-name "::=" diameter-message

diameter-name = ALPHA *(ALPHA / DIGIT / "-")

command-name = diameter-name
; The command-name has peers. See [11] for more information.

Since enforcing policies requires an understanding of the service
being provided, Proxies MUST only advertise the Diameter applications
they support.

2.5.3 Redirector Agents

Redirector agents provide Realm to Server address resolution, and use
the Diameter routing table to determine where a given request should
be Command name,
; defined forwarded to. When a request is received by a Diameter redirector,
a special answer is created, which includes the identity of the
Diameter server(s) the originator of the request should contact
directly.

Redirectors are useful in scenarios where the base or extended Diameter
; specifications.

diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed]

header = "<Diameter-Header:" command-id, message-flags">" routing
configuration needs to be centralized. An example is a redirector
that provides services to all members of a consortium, but does not
wish to be burdened with relaying all messages between domains. This
scenario is advantageous since it does not require that the
consortium provide routing updates to its members when changes are

Calhoun et al. expires October December 2001 [Page 18]

Internet-Draft May June 2001

fixed = [qual] "<" avp-spec ">"

made to a member's infrastructure.

Since redirectors do not relay messages, and only return an answer
with the information necessary for Diameter agents to communicate
directly, they do not modify messages, and therefore MUST NOT
maintain session state. Further, since redirectors never relay
requests, they are not required = [qual] "{" avp-spec "}"

optional = [qual] "[" avp-name "]"
; to maintain transaction state.

+------+
| |
| DRD |
| |
+------+
^ |
2. Request | | 3. Redirection
| | Notification
| v
+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 4. Request | |
| NAS | | DRL | | HMS |
| | 6. Answer | | 5. Answer | |
+------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com
Figure 2: Redirecting a Diameter Message

The avp-name example provided in Figure 2 depicts a request issued from the 'optional' rule cannot
; evaluate
access device, NAS, for the user bob@abc.com. The message is
forwarded by the NAS to any AVP Name its relay, DRL, which is included
; does not have a routing
entry in its Diameter Routing Table for abc.com. DRL has a fixed or required rule.

qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 section 6.6.
; The absence of any qualifiers implies default
route configured to DRD, which is a redirector that one
; and only one such AVP MUST be present.
;
; NOTE: "[" and "]" have returns a different meaning
; than in ABNF (see the optional rule, above).
; These braces cannot be used
redirect notification to express
; optional fixed rules (such DLR, as an optional
; ICV at well as HMS' contact information.
Upon receipt of the end.) To do this, the convention
; is '0*1fixed'.

min = 1*DIGIT
; The minimum number of times redirect notification, DRL establishes a
transport connection with HMS, if one doesn't already exist, and
forwards the element may
; be present.

max = 1*DIGIT
; The maximum number of times request to it.

Since Redirectors do not perform any application level processing,
they provide relaying services for all Diameter applications, and
therefore MUST advertise the element may
; be present.

avp-spec = diameter-name
; The avp-spec has Relay Application Identifier.

2.5.4 Translation Agents

A Translation Agent is a device that provides translation between two
protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation
agents are likely to be an AVP Name, defined
; in the base or extended used as aggregation servers to communicate
with a Diameter
; specifications.

avp-name = avp-spec | "AVP"
; The string "AVP" stands infrastructure, while allowing for *any* arbitrary
; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in
; the command code definition.

The following is a definition of embedded
systems to be migrated at a fictitious command code:

Example-Request ::= < Diameter-Header: 9999999, E >
{ User-Name }
* { Origin-FQDN }
* [ AVP ] slower pace.

Calhoun et al. expires October December 2001 [Page 19]

Internet-Draft May June 2001

3.3

Given that the Diameter Command Naming Conventions

The following conventions are required for protocol introduces the naming concept of Diameter
messages. Diameter commands typically start with an object name, long-lived
authorized sessions, translation agents MUST be stateful and
end with one MUST
maintain transaction state.

Translation of messages can only occur if the following verbs:

3.3.1 Request/Answer

The Request/Answer message pair is used when a Diameter node requests
that some action be performed by a peer (e.g. authorize a user,
terminate agent recognizes the
application of a session). The corresponding message particular request, and therefore MUST contain either a
positive or negative result code, informing the requester whether the
request was successful or not. Other information MAY also be returned
in the Answer message. only
advertise their locally supported applications.

+------+ ---------> +------+ ---------> +------+
| | RADIUS Request and | | Diameter Request | |
| NAS | | TLA | | HMS |
| | RADIUS Answer messages share the same command code, | | Diameter Answer | |
+------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com
Figure 3: Translation of RADIUS to Diameter

2.6 Diameter Agent Discovery

Allowing for dynamic Diameter agent discovery will make it possible
for simpler and more robust deployment of AAA services. In order to
promote interoperable implementations of Diameter agent discovery,
the
message flags field in the following mechanisms are described. These are based on existing
IETF standards.

There are two cases where Diameter header agent discovery may be performed.
The first is used when a Diameter client needs to identify
whether discover a message is the request or answer.

3.3.2 Indication/Failed Indication

Indication first-hop
Diameter agent. The second case is used either when the node wishes a Diameter agent needs to inform
discover another agent - for further handling of a Diameter
operation. In both cases, the peer
that an event occurred, or following 'search order' is requesting that a particular function
recommended:

1. The Diameter implementation consults its list of static
(manual) configured Diameter agent locations. These will be performed, but is not expecting a response. A successfully
processed Indication message is not responded to. However, should an
Indication message cause an error, a response is returned with the
'I' bit cleared
used if they exist and the 'F' bit set in the respond.

2. The Diameter header's message
flags field.

4.0 implementation uses SLPv2 [28] to discover
Diameter AVPs

Diameter AVPs carry specific authentication, accounting and
authorization information, security information as well as
configuration details for the request and reply.

Some AVPs MAY be listed more than once. services. The effect of such an AVP is
specific, and Diameter service template [32] is specified
included in each case by the AVP description.

Each AVP of type OctetString MUST Appendix A. It is recommended that SLPv2 security
be padded deployed (this requires distributing keys to align on a 32 bit
boundary, while other AVP types align naturally. NULL bytes are added SLPv2 agents.)
This is discussed further in Appendix A.

SLPv2 will allow Diameter implementations to discover the end of the AVP Data field till a word boundary is reached. The
length
location of the padding is not reflected Diameter agents in the AVP Length field.

4.1 AVP Header local site, as well as their
characteristics. Diameter agents with specific capabilities
(say support for the Mobile IP application) can be requested,
and only those will be discovered.

Calhoun et al. expires October December 2001 [Page 20]

Internet-Draft May June 2001

3. The fields in Diameter implementation uses DNS to request the AVP header MUST be sent SRV RR [33]
for the '_diameter._sctp' and/or '_diameter._tcp' server in network byte order. a
particular domain. The
format of Diameter implementation has to know in
advance which domain to look for an Diameter agent in. This
could be deduced, for example, from the header is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length | Reserved |P|r|V|r|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+

AVP Code
The AVP Code identifies 'realm' in a NAI that
an Diameter implementation needed to perform an Diameter
operation on.

Diameter allows AAA peers to protect the attribute uniquely. The first 256 AVP
numbers are reserved for backward compatibility with RADIUS integrity and
are privacy
of communication as well as to be interpreted perform end-point
authentication. Still, it is prudent to employ DNS Security as per NASREQ [7]. AVP numbers 256 and above
a precaution when using DNS SRV RRs to look up the location of
a Diameter agent. [34, 35, 36]

2.7 Diameter Identity Encoding

Several Diameter AVPs are used for Diameter, which are allocated by IANA (see section
16.1).

AVP Length
The AVP Length field is two octets, and indicates to include a node's identity, such as
the length Destination-Host, Origin-Host, Route-Record, etc. The contents of
this AVP including
such AVPs follow the AVP Code, AVP Length, AVP Flags, Reserved, Uniform Resource Identifiers (URI) syntax [29]
rules specified below:

Diameter-Identity = [protocol] fqdn [ port ]
[ transport ]

protocol-name = ( "diameter" | "radius" | "tacacs+" )

protocol = protocol-name "://"
; If absent, the Vendor-ID field (if present) and default is "diameter://"

fqdn = Fully Qualified Host Name

port = ":" 1*DIGIT
; If absent, the AVP data. default Diameter port (TBD) is assumed.

transport = ";transport=" ( "tcp" | "sctp" | "udp")
; If a message absent, the default SCTP [26] protocol is
received with an invalid attribute length, assumed.
; UDP is ONLY used when the message SHOULD be
rejected.

AVP Flags protocol is set to RADIUS

The AVP Flags field informs the following are examples of valid Diameter host how each attribute
must be handled. Note that subsequent identities:

host.abc.com:6666;transport=tcp
diameter://host.abc.com
diameter://host.abc.com:6666
diameter://host.abc.com;transport=tcp
diameter://host.abc.com:6666;transport=tcp
radius://host.abc.com:1813;transport=udp

Calhoun et al. expires December 2001 [Page 21]

Internet-Draft June 2001

3.0 Diameter extensions MAY
define bits to be used within Header

A summary of the AVP Header, and an unrecognized
bit should be considered an error. Diameter header format is shown below. The 'r' and the reserved bits fields
are unused and should transmitted in network byte order.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R r r r r r r r| Command-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop-by-Hop Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End-to-End Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVPs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Version
This Version field MUST be set to 0 and ignored on receipt, while
the 'P' bit is defined in [11]. 1 to indicate Diameter Version
1.

Message Length
The 'M' Bit, known as the Mandatory bit, Message Length field is two octets and indicates whether support the length of
the AVP Diameter message including the header fields.

Command Flags
The Command Flags field is required. eight bits. The following bits are
assigned:

R(equest) - If an AVP is received by a Home server or
NAS with the 'M' bit enabled and the receiver does not support
the AVP, set, the message MUST be rejected. If such an AVP is received
by a Proxy or Redirect Server, request. If cleared, the
message is an answer.
r(eserved) - this flag bit is reserved for future use, and MUST
be forwarded set to
its logical destination, zero.

Command-Code
The Command-Code field is three octets, and MUST NOT be rejected. It is used in order to
communicate the
responsibility of command associated with the originator of a message that is rejected for
this purpose to correct the error. 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.

Calhoun et al. expires October 2001 [Page 21]

Internet-Draft May 2001 message. The 'V' bit, known as the Vendor-Specific bit, indicates whether
the optional Vendor-ID field 24-bit
address space is present in the AVP header. When
set the AVP Code belongs to managed by IANA (see section 15.2).

Vendor-ID
In the specific vendor code address
space.

Unless otherwise noted, AVPs will have event that the following default AVP
Flags Command-Code field settings:
The 'M' bit MUST be set. The 'V' bit MUST NOT be set.

4.2 Optional Header Elements

The AVP Header contains one optional field. This field is only
present if the respective bit-flag is enabled.

Vendor-ID
The Vendor-ID field is present if the 'V' bit is set in a vendor
specific command, the AVP
Flags field. The optional four octet Vendor-ID field contains the IANA
assigned "SMI Network Management Private Enterprise Codes" [2] value, encoded in network byte order.
value. If the Command-Code field contains an IETF standard

Calhoun et al. expires December 2001 [Page 22]

Internet-Draft June 2001

Command, the Vendor-ID field MUST be set to zero (0). Any vendor
wishing to implement a vendor-specific Diameter extension command MUST use
their own Vendor-ID along with their privately managed AVP Command-
Code address space, guaranteeing that they will not collide with
any other vendor's extensions, vendor-specific command, nor with future IETF extensions.

A vendor ID value of zero (0) corresponds to the IETF adopted AVP
values, as managed by the IANA. Since the absence of the vendor ID
applications.

Hop-by-Hop Identifier
The Hop-by-Hop Identifier field implies is four octets, and aids in
matching requests and replies. The sender MUST ensure that the AVP
Hop-by-Hop identifier in question a request is not vendor specific,
implementations SHOULD not use locally unique (to the zero (0) vendor ID.

4.3 AVP Data Formats

The Data field is zero or more octets
sender) at any given time, and contains information
specific MAY attempt to ensure that the Attribute. The format and length of the Data field
number is
determined by the AVP Code and AVP Length fields. unique across reboots. The format sender of an Answer message
MUST ensure that the
Data Hop-by-Hop Identifier field MAY be one of the following data types.

The interpretation of the values depends on contains the specification of same
value that was found in the
AVP. For example, corresponding request. The Hop-by-Hop
identifier is normally a monotonically increasing number, whose
start value was randomly generated. An answer message that is
received with an OctetString may unknown Hop-by-Hop Identifier MUST be discarded.

End-to-End Identifier
Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is
used to transmit human
readable string data detect duplicate messages, and Unsigned32 may be used to transmit relay agents MUST NOT
modify this field. The sender of a time
value. Conventions for these common interpretations are described
below.

OctetString request or answer message MUST
insert a locally unique value in this field. The data contains arbitrary data combination of variable length. Unless
otherwise noted,
the Origin-Host AVP Length and this field MUST be set to at least 9
(13 if the 'V' bit is enabled). Data used to transmit (human

Calhoun et al. expires October 2001 [Page 22]

Internet-Draft May 2001

readable) character string data uses the UTF-8 [24] character
set detect duplicates.
An Answer message which is received with a previously seen End-
to-End Identifier, and is NOT NULL-terminated. The minimum Length field MUST to be 9, but can be set to any value up to 65504 bytes. AVP Values
of this type locally consumed (meaning that do not align on a 32-bit boundary MUST have
the necessary padding.

Address
32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most
significant octet first. The format of the address (IPv4 or
IPv6) is determined by the length. If the attribute value is an
IPv4 address, the
Destination-Host AVP Length field MUST be 12 (16 if 'V' bit is
enabled), otherwise contains the AVP Length field MUST local node's identity) SHOULD be set
silently discarded.

AVPs
AVPs are a method of encapsulating information relevant to 24 (28
if the 'V' bit is enabled)
Diameter message. See section 4. for IPv6 addresses.

Integer32
32 bit signed value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit more information on AVPs.

3.1 Command Codes

Each command Request/Answer pair is enabled).

Integer64
64 bit signed value, in network byte order. The AVP Length
field MUST be set to 16 (20 if assigned a command code, and the 'V' bit
sub-type (e.g. request or answer) is enabled).

Unsigned32
32 identified via the 'R' bit unsigned value, in network byte order. The AVP Length
the Command Flags field of the Diameter header.

Every Diameter message MUST be set contain a command code in its header's
Command-Code field, which is used to 12 (16 if determine the 'V' bit action that is enabled).
Unsigned32 values used to transmit time data contains
be taken for a particular message. The following Command Codes are
defined in the four
most significant octets returned from NTP [18], in network byte
order.

Unsigned64
64 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 16 (20 if the 'V' bit is enabled).

Float32
This represents floating point values of single precision as
described by [30]. The 32 bit value is transmitted in network
byte order. The AVP Length field MUST be set to 12 (16 if the
'V' bit is enabled).

Float64
This represents floating point values of double precision as
described by [30]. The 64 bit value is transmitted in network
byte order. The AVP Length field MUST be set to 16 (20 if the
'V' bit is enabled).

Float128
This represents floating point values of quadruple precision as
described by [30]. The 128 bit value is transmitted in network Diameter base protocol:

Calhoun et al. expires October December 2001 [Page 23]

Internet-Draft May June 2001

byte order. The AVP Length field

Command-Name Abbrev. Code Reference
--------------------------------------------------------
Abort-Session-Request ASR 274 10.8.1
Abort-Session-Answer ASA 274 10.8.2
Accounting-Answer ACA 271 12.2
Accounting-Poll-Ind API 273 12.3
Accounting-Request ACR 271 12.1
Capabilities-Exchange- CER 257 6.2
Request
Capabilities-Exchange- CEA 257 6.3
Answer
Message-Reject-Answer MRA 282 9.2
Device-Watchdog-Answer DWA 280 7.2
Device-Watchdog-Request DWR 280 7.1
Session-Termination- STR 275 10.7.1
Request
Session-Termination- STA 275 10.7.2

3.2 Command Code ABNF specification

Every Command Code defined MUST be set include a corresponding ABNF
specification, which is used to 24 (28 if define the
'V' bit is enabled).

Grouped
The Data field is specified as a sequence of AVPs. Each of
these AVPs follows - in the order in which they are specified -
including their headers that MUST, MAY and padding.
MUST NOT be present. The AVP Length field following format is
set to 8 (12 if the 'V' bit is enabled) plus used in the total length
of all included AVPs, including their headers and padding.

4.4 Grouped AVP Values definition:

command-def = command-name "::=" diameter-message

diameter-name = ALPHA *(ALPHA / DIGIT / "-")

command-name = diameter-name
; The Diameter protocol allows AVP values of type 'Grouped.' This
implies that the Data field is actually a well defined sequence of
AVPs. It is possible to include an AVP with a Grouped type within a
Grouped type, that is, command-name has to nest them. AVPs within an AVP of type
Grouped have the same padding requirements as non-Grouped AVPs, as
defined in section 4.0.

Grouped type AVP specifications include an ABNF grammar [31]
specifying the required sequence of AVPs. Grouped AVP values MUST be Command name,
; defined in the specified sequence and MUST NOT include other AVP values
besides those specified by the Grouped AVP grammar.

4.4.1 Example AVP with a Grouped Data type base or extended Diameter
; specifications.

diameter-message = header [ *fixed] [ *required] [ *optional]
[ *fixed]

header = "<Diameter-Header:" command-id [r-bit] ">"

command-id = 1*DIGIT
; The Example AVP (AVP Command Code 999999) is of type Grouped and is used assigned to
clarify how Grouped AVP values work. The Grouped Data field has the
following ABNF grammar:

example-avp-val = Origin-FQDN Host-IP-Address
Origin-FQDN command

r-bit = ", REQUEST"
; See Section 5.1
Host-IP-Address = If present, the 'R' bit in the Command
; See Section 6.2.4

An Example AVP with Flags is set, indicating that the Grouped Data Origin-FQDN = "example.com",
Host-IP-Address = "10.10.10.10" would be encoded message
; is a request, as follows: opposed to an answer.

fixed = [qual] "<" avp-spec ">"

Calhoun et al. expires October December 2001 [Page 24]

Internet-Draft May June 2001

0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code

required = 999999), Length [qual] "{" avp-spec "}"

optional = 40 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-FQDN [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Header (AVP Code = 264), Length Name which is included
; in a fixed or required rule.

qual = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Host-IP-Addr [min] "*" [max]
; See ABNF conventions, RFC 2234 section 6.6.
; The absence of any qualifiers implies that
; one and only one such AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code MUST be present.
;
; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above).
; These braces cannot be used to express
; optional fixed rules (such as an optional
; ICV at the end.) To do this, the convention
; is '0*1fixed'.

min = 257), Length 1*DIGIT
; The minimum number of times the element may
; be present.

max = 12 | 0x0a | 0x0a | 0x0a | 0x0a |
+-------+-------+-------+-------+-------+-------+-------+-------+

4.5 Diameter Base Protocol AVPs 1*DIGIT
; The following table describes maximum number of times the Diameter AVPs element may
; be present.

avp-spec = diameter-name
; The avp-spec has to be an AVP Name, defined
; in the base
protocol, their AVP Code values, types, possible flag values and
whether the AVP MAY be encrypted.

+---------------------+
| AVP or extended Diameter
; specifications.

avp-name = avp-spec | "AVP"
; The string "AVP" stands for *any* arbitrary
; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in
; the command code definition.

The following is a definition of a fictitious command code:

Example-Request ::= < Diameter-Header: 9999999, REQUEST >
{ User-Name }
* { Origin-Host }
* [ AVP ]

3.3 Diameter Command Naming Conventions

Calhoun et al. expires December 2001 [Page 25]

Internet-Draft June 2001

The following conventions are required for the naming of Diameter
messages. Diameter commands typically start with an object name, and
end with either the Request or Answer verb.

The Request/Answer message pair is used when a Diameter node requests
that some action be performed by a peer (e.g. authorize a user,
terminate a session). The corresponding answer MUST contain either a
positive or negative result code, informing the requester whether the
request was successful or not. Other information MAY also be returned
in the Answer message.

Request and Answer messages share the same command code, and the
R(equest) bit in the Diameter header is used to identify whether a
message is the request or answer.

4.0 Diameter AVPs

Diameter AVPs carry specific authentication, accounting and
authorization information, security information as well as
configuration details for the request and reply.

Some AVPs MAY be listed more than once. The effect of such an AVP is
specific, and is specified in each case by the AVP description.

Each AVP of type OctetString MUST be padded to align on a 32 bit
boundary, while other AVP types align naturally. NULL bytes are added
to the end of the AVP Data field till a word boundary is reached. The
length of the padding is not reflected in the AVP Length field.

4.1 AVP Header

The fields in the AVP header MUST be sent in network byte order. The
format of the header is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+

Calhoun et al. expires December 2001 [Page 26]

Internet-Draft June 2001

AVP Code
The AVP Code, combined with the Vendor-Id field, identifies the
attribute uniquely. The first 256 AVP numbers are reserved for
backward compatibility with RADIUS and are to be interpreted as
per NASREQ [7]. AVP numbers 256 and above are used for Diameter,
which are allocated by IANA (see section 15.1).

AVP Flags
The AVP Flags field informs the receiver how each attribute must
be handled. Note that subsequent Diameter applications MAY define
bits to be used within the AVP Header, and an unrecognized bit
should be considered an error. The 'r' and the reserved bits are
unused and should be set to 0 and ignored on receipt, while the
'P' bit is defined in [11].

The 'M' Bit, known as the Mandatory bit, indicates whether support
of the AVP is required. If an unrecognized AVP with the 'M' bit
set is received by a Diameter node, the message MUST be rejected.
Diameter Relay and Redirector agents MUST NOT reject messages with
unrecognized AVPs.

A Diameter node that sets the 'M' bit in an AVP that is not
defined in a given message's ABNF is at fault if the message is
rejected. In order to provide service to the user, the node at
fault MUST re-issue a request either without the AVP, or without
setting its 'M' bit.

A Diameter node that rejects a message due to an unrecognized AVP
with the 'M' bit set, and the AVP in question is defined in the
message's ABNF is at fault. In most cases the initiator of the
failing request will not provide service to the user.

AVPs with the 'M' bit cleared are informational only and a
receiver that receives a message with such an AVP that is not
supported MAY simply ignore the AVP.

The 'V' bit, known as the Vendor-Specific bit, indicates whether
the optional Vendor-ID field is present in the AVP header. When
set the AVP Code belongs to the specific vendor code address
space.

Unless otherwise noted, AVPs will have the following default AVP
Flags field settings:
The 'M' bit MUST be set. The 'V' bit MUST NOT be set.

AVP Length
The AVP Length field is three octets, and indicates the length of
this AVP including the AVP Code, AVP Length, AVP Flags, Reserved,

Calhoun et al. expires December 2001 [Page 27]

Internet-Draft June 2001

the Vendor-ID field (if present) and the AVP data. If a message is
received with an invalid attribute length, the message SHOULD be
rejected.

4.2 Optional Header Elements

The AVP Header contains one optional field. This field is only
present if the respective bit-flag is enabled.

Vendor-ID
The Vendor-ID field is present if the 'V' bit is set in the AVP
Flags field. The optional four octet Vendor-ID field contains the
IANA assigned "SMI Network Management Private Enterprise Codes"
[2] value, encoded in network byte order. Any vendor wishing to
implement a vendor-specific Diameter AVP MUST use their own
Vendor-ID along with their privately managed AVP address space,
guaranteeing that they will not collide with any other vendor's
vendor-specific AVP, nor with future IETF applications.

A vendor ID value of zero (0) corresponds to the IETF adopted AVP
values, as managed by the IANA. Since the absence of the vendor ID
field implies that the AVP in question is not vendor specific,
implementations SHOULD not use the zero (0) vendor ID.

4.3 AVP Data Formats

The Data field is zero or more octets and contains information
specific to the Attribute. The format and length of the Data field is
determined by the AVP Code and AVP Length fields. The format of the
Data field MAY be one of the following data types.

The interpretation of the values depends on the specification of the
AVP. For example, an OctetString may be used to transmit human
readable string data and Unsigned32 may be used to transmit a time
value. Conventions for these common interpretations are described
below.

OctetString
The data contains arbitrary data of variable length. Unless
otherwise noted, the AVP Length field MUST be set to at least 8
(12 if the 'V' bit is enabled). Data used to transmit (human
readable) character string data uses the UTF-8 [24] character
set and is NOT NULL-terminated. The minimum Length field MUST
be 9, but can be set to any value up to 65504 bytes. AVP Values
of this type that do not align on a 32-bit boundary MUST have
the necessary padding.

Calhoun et al. expires December 2001 [Page 28]

Internet-Draft June 2001

Address
32 bit (IPv4) [17] or 128 bit (IPv6) [16] address, most
significant octet first. The format of the address (IPv4 or
IPv6) is determined by the length. If the attribute value is an
IPv4 address, the AVP Length field MUST be 12 (16 if 'V' bit is
enabled), otherwise the AVP Length field MUST be set to 24 (28
if the 'V' bit is enabled) for IPv6 addresses.

Integer32
32 bit signed value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit is enabled).

Integer64
64 bit signed value, in network byte order. The AVP Length
field MUST be set to 16 (20 if the 'V' bit is enabled).

Unsigned32
32 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit is enabled).
Unsigned32 values used to transmit time data contains the four
most significant octets returned from NTP [18], in network byte
order.

Unsigned64
64 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 16 (20 if the 'V' bit is enabled).

Float128
This represents floating point values of quadruple precision as
described by [30]. The 128 bit value is transmitted in network
byte order. The AVP Length field MUST be set to 24 (28 if the
'V' bit is enabled).

Grouped
The Data field is specified as a sequence of AVPs. Each of
these AVPs follows including their headers and padding. The

Calhoun et al. expires December 2001 [Page 29]

Internet-Draft June 2001

AVP Length field is set to 8 (12 if the 'V' bit is enabled)
plus the total length of all included AVPs, including their
headers and padding.

4.4 Grouped AVP Values

The Diameter protocol allows AVP values of type 'Grouped.' This
implies that the Data field is actually a sequence of AVPs. It is
possible to include an AVP with a Grouped type within a Grouped type,
that is, to nest them. AVPs within an AVP of type Grouped have the
same padding requirements as non-Grouped AVPs, as defined in section
4.0.

Every Grouped AVP defined MUST include a corresponding grammar, using
ABNF [31] (with modifications), as defined below.

avp-def = name "::=" avp

name-fmt = ALPHA *(ALPHA / DIGIT / "-")

name = name-fmt
; The name has to be the name of an AVP,
; defined in the base or extended Diameter
; specifications.

avp = header [ *fixed] [ *required] [ *optional]
[ *fixed]

header = "<AVP-Header:" avpcode ">"

avpcode = 1*DIGIT
; The AVP Code assigned to the Grouped AVP

fixed = [qual] "<" avp-spec ">"

required = [qual] "{" avp-spec "}"

optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included
; in a fixed or required rule.

qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 section 6.6.
; The absence of any qualifiers implies that
; one and only one such AVP MUST be present.
;

Calhoun et al. expires December 2001 [Page 30]

Internet-Draft June 2001

; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above).
; These braces cannot be used to express
; optional fixed rules (such as an optional
; ICV at the end.) To do this, the convention
; is '0*1fixed'.

min = 1*DIGIT
; The minimum number of times the element may
; be present.

max = 1*DIGIT
; The maximum number of times the element may
; be present.

avp-spec = name-fmt
; The avp-spec has to be an AVP Name, defined
; in the base or extended Diameter
; specifications.

avp-name = avp-spec | "AVP"
; The string "AVP" stands for *any* arbitrary
; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in
; the command code definition.

4.4.1 Example AVP with a Grouped Data type

The Example AVP (AVP Code 999999) is of type Grouped and is used to
clarify how Grouped AVP values work. The Grouped Data field has the
following ABNF grammar:

Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ]

An Example AVP with Grouped Data follows.

The Origin-Host AVP is required. In this case:

Origin-Host = "example.com".

One or more Session-Ids must follow. Here there are two:

Session-Id =
"grump.example.com:33041;23432;893;0AF3B81"

Calhoun et al. expires December 2001 [Page 31]

Internet-Draft June 2001

Session-Id =
"grump.example.com:33054;23561;2358;0AF3B82"

optional AVPs included are

Recovery-Policy = <binary>
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92

Futuristic-Acct-Record = <binary>
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841

The data for the optional AVPs is represented in hex since the format
of these AVPs is neither known at the time of definition of the
Example-AVP group, nor (likely) at the time when the example instance
of this AVP is interpreted - except by Diameter implementations which
support the same set of AVPs. The encoding example illustrates how
padding is used, how length fields are calculated and how AVPs do not
have to begin on 8 byte boundaries. Also note that AVPs may be
present in the Grouped AVP value which the receiver cannot interpret
(here, the Recover-Policy and Futuristic-Acct-Record AVPs).

This AVP would be encoded as follows:

Calhoun et al. expires December 2001 [Page 32]

Internet-Draft June 2001

0 1 2 3 4 5 6 7
+-------+-------+-------+-------+-------+-------+-------+-------+
0 | Example AVP Header (AVP Code = 999999), Length = 468 |
+-------+-------+-------+-------+-------+-------+-------+-------+
8 | Origin-Host AVP Header (AVP Code = 264), Length = 19 |
+-------+-------+-------+-------+-------+-------+-------+-------+
16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.' |
+-------+-------+-------+-------+-------+-------+-------+-------+
24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header |
+-------+-------+-------+-------+-------+-------+-------+-------+
32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
64 | 'A' | 'F' | '3' | 'B' | '8' | '1' |Padding|Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
68 | Session-Id AVP Header (AVP Code = 263), Length = 51 |
+-------+-------+-------+-------+-------+-------+-------+-------+
72 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x' |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2' |Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
112 | Recovery-Policy Header (AVP Code = 8341), Length = 223 |
+-------+-------+-------+-------+-------+-------+-------+-------+
120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71 |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92 |Padding|
+-------+-------+-------+-------+-------+-------+-------+-------+
328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length = 137|
+-------+-------+-------+-------+-------+-------+-------+-------+
336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b |
+-------+-------+-------+-------+-------+-------+-------+-------+
. . .
+-------+-------+-------+-------+-------+-------+-------+-------+
464 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+

4.5 Diameter Base Protocol AVPs

The following table describes the Diameter AVPs defined in the base
protocol, their AVP Code values, types, possible flag values and
whether the AVP MAY be encrypted.

Calhoun et al. expires December 2001 [Page 33]

Internet-Draft June 2001

+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Accounting- 482 14.2 13.2 Unsigned32 | M | P | | V | Y |
Interim-Interval | | | | | |
Accounting- 50 13.5 OctetString| M | P | | V | Y |
Multi-Session-Id | | | | | |
Accounting- 485 14.3 13.3 Unsigned32 | M | P | | V | Y |
Record-Number | | | | | |
Accounting- 480 14.1 13.1 Unsigned32 | M | P | | V | Y |
Record-Type | | | | | |
Accounting- 44 14.5 13.4 OctetString| M | P | | V | Y |
Session-Id | | | | | |
Accounting-State 486 14.4 Unsigned32 | M | P | | V | Y |
Acct-Extension-
Acct- 259 6.2.7 6.10 Integer32 | M | | | V | Y N |
Id
Application-Id | | | | | |
Auth-Extension-
Auth- 258 6.2.3 6.6 Integer32 | M | | | V | Y N |
Id
Application-Id | | | | | |
Authorization- 291 10.4 Unsigned32 | M | | | V | N |
Lifetime | | | | | |
Destination-FQDN
Destination-Host 293 5.3 5.6 OctetString| M | | | V | Y N |
Destination- 283 11.4.7 5.7 OctetString| M | | | V | N |
Realm | | | | | |
DSI-Event 297 9.2.2 Unsigned32 | M | | | | N |
Error-Message 281 9.1.2 9.3 OctetString| | | | V | N |
-----------------------------------------|----+-----+----+-----|----|

Calhoun et al. expires October 2001 [Page 25]

Internet-Draft May 2001

+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Error-Reporting- 294 9.1.3 9.4 OctetString| | | | V | Y N |
FQDN
Host | | | | | |
Failed-AVP 279 9.3 OctetString| M | | | | Y |
Failed-Vendor-Id 262 9.5 Unsigned32 | OctetString| M | | | V | Y |
Firmware- 267 6.2.2 6.5 Unsigned32 | | | | V,M | Y N |
Revision | | | | | |
Host-IP-Address 257 6.2.4 6.7 Address | M | | | V | N |
Max-Wait-Time 295 10.7 Unsigned32 | M | | | V | N |
Offending-AVP 271 9.4 OctetString| M | | | V | N |
Origin-FQDN
Origin-Host 264 5.1 5.4 OctetString| M | | | V | N |
Origin-Realm 296 5.2 5.5 OctetString| M | | | V | N |
Product-Name 269 6.2.6 6.9 OctetString| | | | | N |
Proxy-Address
Proxy-Host 280 11.4.5 5.8.3 Address | M | | | V | N |
Proxy-Info 284 11.4.4 5.8.2 Grouped | M | | | V | N |
Proxy-State 33 11.4.6 5.8.4 OctetString| M | | | V | N |
Redirect-Host 292 11.3.1 Grouped | 5.9 OctetString| M | | | V | Y |
Redirect-Host- 278 11.3.2 Address
Result-Code 268 9.1 Unsigned32 | M | | | V | Y |
Address | N |
Route-Record 282 5.8.1 OctetString| M | | | V |
Redirect-Host- 277 11.3.3 Unsigned32 N |
Session-Id 263 10.3 OctetString| M | | | V | Y |
Port
Session-Timeout 27 10.5 Unsigned32 | M | | | V | N |
Result-Code 268 9.1.1
Origin-State-Id 278 10.11 Unsigned32 | M | | | V | N |
Route-Record 282 11.4.3 OctetString|
Supported- 265 6.8 Unsigned32 | M | | | V | N |
Session-Id 263 10.3 OctetString| M
Vendor-Id | | | | Y |
Session-Timeout 27 10.5 Unsigned32 | M
-----------------------------------------|----+-----+----+-----|----|

Calhoun et al. expires December 2001 [Page 34]

Internet-Draft June 2001

+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | Y |SHLD| MUST|MAY |
Supported- 265 6.2.5
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Termination- 295 10.9 Unsigned32 | M | | | V | N |
Vendor-Id
Cause | | | | | |
User-Name 1 10.6 OctetString| M | | | V | Y |
Vendor-Id 266 6.2.1 6.4 Unsigned32 | M | | | V,M | Y N |
Vendor-Specific- 260 6.11 Grouped | M | | | V,M | N |
Application-Id
-----------------------------------------|----+-----+----+-----|----|

5.0 Message Forwarding Diameter message processing

All Diameter messages MUST include the Origin-FQDN and Origin-Realm
AVPs. These AVPs are used to identify the source of the message.
When responding to a request or indication (via a failed indication)
message, the Origin-FQDN Origin-Host and Origin-Realm AVPs
AVPs, which are replaced with used to identify the
local node's information. source of the message. The
Destination-Host AVP MAY be present in requests, and MUST be present
in answers. The Destination-FQDN Destination-Host AVP is used when the destination of
the message is fixed, such as:

Calhoun et al. expires October 2001 [Page 26]

Internet-Draft May 2001 which includes:

- Authentication requests that span multiple round trips
- A Diameter message that uses a security mechanism that makes use
of a pre-established session key shared between the source and
the final destination of the message.
- Server initiated messages that MUST be received by a specific
Diameter client (e.g. access device), such as the Session-
Termination-Ind Abort-
Session-Request message, which is used to request that a
particular user's session be terminated.

A message that includes the Destination-FQDN AVP containing the local
hosts' identity is to be locally processed.

Proxies receiving messages that contain the Destination-FQDN

The Destination-Realm AVP MUST
verify whether they are able to forward Diameter messages to the host
specified in the AVP, and be present if so, MUST forward the message to the host
in question. Otherwise, the is routable.
A message routing procedures described in
section 11.0 MUST be followed.

Unless otherwise specified, this section defines the Diameter AVPs that MUST NOT be added relayed, proxied or redirected MUST NOT
include the Destination-Realm in all messages originated by a Diameter node
(including nodes creating Answer messages).

5.1 Origin-FQDN AVP its ABNF. The Origin-FQDN AVP (AVP Code 264) is value of type OctetString, encoded in the UTF-8 [24] format. This
Destination-Realm AVP identifies the endpoint which
originated the Diameter message, i.e. the access device, home server,
or broker. Proxy servers do not modify this AVP. All Diameter
messages MUST include MAY be extracted from the Origin-FQDN User-Name AVP, which contains or
other application-specific methods.

When a message is received, the host
name of message is processed in the originator of following
order:
1. If the Diameter message and MUST follow the
Fully Qualified Domain Name naming conventions.

Note that is destined for the Origin-FQDN AVP may resolve to more than one address as local host, the Diameter peer may support more than one address.

5.2 Origin-Realm AVP

The Origin-Realm AVP (AVP Code 296) is of type OctetString, encoded procedures
listed in section 5.1 are followed.
2. If the UTF-8 [24] format. This AVP contains message is intended for a Diameter peer with whom the Realm of
local host is able to directly communicate with, the
originator of any Diameter message.

5.3 Destination-FQDN AVP

The Destination-FQDN AVP (AVP Code 293) procedures
listed in section 5.2 are followed. This is of type OctetString,
encoded known as Message
Forwarding.
3. The procedures listed in the UTF-8 [24] format, and contains the Fully Qualified section 5.3 are followed, which is
known as Message Routing.

Calhoun et al. expires October December 2001 [Page 27] 35]

Internet-Draft May June 2001

Domain Name (FQDN)

4. If none of the intended recipient of above are successful, an answer is returned with
the message. This AVP
MUST be present Result-Code set to DIAMETER_UNABLE_TO_DELIVER.

Note the processing rules contained in all unsolicited server initiated messages, this section are intended to
be used as general guidelines to Diameter developers. Certain
implementations MAY use different methods than the ones described
here, and still be
present in compliance with the protocol specification.

5.1 Processing Local Messages

A request or indication message, and MUST is known to be present in
Answer or failed Indication messages. The value for local comsumption when one of the Destination-
FQDN
following conditions occur:
- The Destination-Host AVP is set to contains the value of local host's identity,
- The Destination-Host AVP is not present, the Origin-FQDN Destination-Realm
AVP found in contains a
message from realm the server is configured to process
locally, and the intended target host.

6.0 Capabilities Exchange

When two Diameter peers establish application is locally supported, or
- The Destination-Realm AVP is not present.

When a transport connection, they MUST
send request is locally processed, the Device-Reboot-Ind message. This message has two purposes.
First it allows a peer's identity following procedures MUST be
applied, in addition to any additional procedures that MAY be discovered, and allows for
capabilities exchange, such as
discussed in the supported protocol version number,
and Diameter application defining the locally supported extensions. command:

- The receiver uses same Hop-by-Hop identifier in the extensions advertised request is used in order to determine
whether it SHOULD send certain application-specific Diameter
commands. A Diameter node MUST retain the supported extensions
answer.
- The local host's identity is encoded in
order to ensure that unrecognized commands and/or AVPs are not sent
to a peer.

A receiver the Origin-Host and
Origin-Host AVPs.
- The value of a Device-Reboot-Ind message which does not have any
extensions the Origin-Host AVP in common with the sender MUST return a DSI message to request is included in
the
peer answer's Destination-Host AVP.
- The Result-Code AVP is added with its value indicating success
or failure.
- If the DSI-Event AVP set to DIAMETER_NO_COMMON_EXTENSION, and
disconnect Session-Id is present in the transport layer connection.

The Device-Reboot-Ind message request, it MUST NOT be proxied, included
in the answer.
- Any Route-Record or redirected.

Since Proxy-Info AVPs in the DRI cannot request MUST be proxied, it is still possible that a upstream
proxy receives a message for which it has no available peers added
to
handle the extension that corresponds to answer message, in the Command-Code. In such
instances, same order they were present in
the Device-Status-Ind request.

When the local message is used (see Section 9.2.1)
to inform an answer, no additional procedures beyond
those listed in the downstream specific Diameter application are to take action.

With be followed.

5.2 Message Forwarding

Message forwarding is done using the exception Diameter Peer Table. The
Diameter peer table contains all of the Device-Reboot-Ind message, a message of
type Request or Indication peers that includes the Auth-Extension-Id or
Acct-Extension-Id AVPs, or a message with an extension-specific
command code, MAY only be forwarded local node is
able to directly communicate with.

When a host that has explicitly
advertised support for request is received, and the extension (or has advertised host encoded in the Wildcard
Extension).

6.1 Extension Identifiers

Each Diameter extension draft MUST have an IANA assigned Extension
Identifier (see section 16.3). The base protocol does not require an
Extension Identifier since its support is mandatory. Destination-

Calhoun et al. expires October December 2001 [Page 28] 36]

Internet-Draft May June 2001

Extension Identifiers are communicated via two separate AVPs; Auth-
Extension-Id and Acct-Extension-Id. The Auth-Extension-Id

Host AVP is used one that is present in the peer table, the message SHOULD
be forwarded to communicate support for the authentication and authorization
portion of peer.

If the message received is an extension. answer, the host in the Destination-
Host AVP is in the peer table, and there are no Route-Record AVPs in
the message, the message MUST be forwarded to the peer.

5.2.1 Peer Table

The Acct-Extension-Id AVP, on Diameter Peer Table is used in message forwarding, and referenced
by the other
hand, communicates support for Domain Routing Table. A Peer Table entry contains the accounting portion
following fields:
- Peer name. The Fully Qualified Domain Name of an
extension. the peer. This separation of AVPs allows a server MAY
be resolved locally, or known via the CER or CEA message.
- Port Number. The port number the peer may be contacted on.
- Protocol. Specifies whether TCP or SCTP is the protocol to use
to communicate that it with the peer.
- TLS Enabled. Specifies whether TLS is
willing to accept only accounting messages for a given extension.

The following Extension Identifier values are defined:

NASREQ 1 [7]
End-to-End Security 2 [11]
Resource Management 3 [29]
Mobile-IP 4 [10]
Wildcard Extension 0xffffffff

Servers acting as Redirect or Proxy servers (see Section 11.0) MAY
wish to either advertise all supported extensions, or be used when
communicating with the peer.

5.3 Message Routing

Diameter request message routing is done via realms. A Diameter
message that is proxyable MUST include the target realm in the wildcard
extension.
Destination-Realm AVP. The receiver realm MAY be retrieved from the User-Name
AVP, which is in the form of a wildcard extension MUST assume that Network Access Identifier (NAI). The
realm portion of the
sender supports all extensions.

Proxy servers are responsible for finding a downstream server that
supports NAI is inserted in the extension Destination-Realm AVP.

Diameter agents have a list of locally supported realms, and MAY have
a particular message. If none can be found, list of externally supported realms. When a DSI message request is returned with the DSI-Event AVP set to
DIAMETER_UNABLE_TO_DELIVER.

6.2 Device-Reboot-Ind (DRI) Command

The Device-Reboot-Ind (DRI), indicated by the Command-Code set to 257
and received
that includes a realm that is not locally supported, the message flags' 'I' bit set, is sent
routed to inform a the peer that a
reboot has, or will, occur.

When Diameter configured in the Domain Routing Table table (see
section 5.3.1).

5.3.1 Realm-Based Routing Table

All Realm-Based routing lookups are performed against what is run over SCTP [26], which allows for connections
commonly known as the Domain Routing Table (see section 16.0). A
Domain Routing Table Entry contains the following fields:
- Domain Name. The Domain Name is analogous to
span multiple interfaces, hence multiple IP addresses, the Device-
Reboot-Ind message MUST contain one Host-IP-Address AVP for each
potential IP address realm portion
of the NAI. This is the field that MAY be locally is typically used when transmitting
Diameter messages.

If a Diameter node receives as a DRI message that results
primary key in an error,
the message MUST be returned with the 'F' bit set, and routing table lookups. Note that some
implementations perform their lookups based on longest-match-
from-the-right on the 'I' bit
cleared.

Message Format realm rather than requiring an exact
match.

Calhoun et al. expires October December 2001 [Page 29] 37]

Internet-Draft May June 2001

<Device-Reboot-Ind> ::= < Diameter Header: 257, I >
{ Origin-FQDN }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
* [ Supported-Vendor-Id ]
* [ Auth-Extension-Id ]
* [ Acct-Extension-Id ]
[ Destination-FQDN ]
[ Firmware-Revision ]
* [ AVP ]

6.2.1 Vendor-Id AVP

The Vendor-Id AVP (AVP Code 266)

- Application Identifier. It is of type Unsigned32 and contains
the IANA "SMI Network Management Private Enterprise Codes" [2] value
assigned possible for a routing entry to
have a different destination based on the vendor Acct-Application-Id
(for accounting messages) or Auth-Application-Id (for non-
accounting messages) of the message. This field is typically
used as a secondary key field in routing table lookups.
- Local Action. The Local Action field is used to identify how a
message should be treated. The following actions are supported:
1. LOCAL - Diameter device.

In combination messages that resolve to a routing entry
with the Supported-Vendor-Id AVP (section 6.2.5), Local Action set to Local can be satisfied
locally, and do not need to be routed to another server.
2. RELAY - All Diameter messages that fall within this
MAY
category MUST be used in order routed to know which vendor specific attributes may a next hop server, without
modifying any non-routing AVPs. See sections 5.3.3 and
5.3.4 for relaying guidelines
3. PROXY - All Diameter messages that fall within this
category MUST be
sent routed to a next hop server. The local
server MAY apply its local policies to the message by
including new AVPs to the peer. It is also envisioned message prior to routing. See
sections 5.3.3 and 5.3.4 for relaying guidelines.
4. REDIRECT - Diameter messages that fall within this
category MUST have the combination identity of the
Vendor-Id, Product-Name (section 6.2.6) home Diameter
server(s) appended, and returned to the Firmware-Revision
(section 6.2.2) AVPs MAY provide very useful debugging information.

A Vendor-Id value sender of zero in the DRI is reserved and indicates that
message. See section 5.3.2 for redirect guidelines.
- Server Identifier - One or more servers the Diameter peer message is to be
routed to. These servers MUST also be present in the experimental or concept stage and that an
IANA Private Enterprise Number has yet Peer
table. When the Local Action is set to RELAY or PROXY, this
field contains the identity of the server(s) the message must be obtained by
routed to. When the
implementor.

6.2.2 Firmware-Revision AVP

The Firmware-Revision AVP (AVP Code 267) Local Action field is set to REDIRECT, this
field contains the identity of type Unsigned32 and one or more servers the message
should be redirected to.

It is
used important to inform a note that Diameter peer agents MUST support at least
one of the firmware revision LOCAL, RELAY, PROXY or REDIRECT modes of the
issuing device.

For devices that operation. Agents
do not have need to support all modes of operation in order to conform
with the protocol specification, but MUST follow the protocol
compliance guidelines in section 2.0. Relay agents MUST NOT reorder
AVPs, and proxies SHOULD NOT reorder AVPs.

When a firmware revision (general purpose
computers running Diameter software modules, request is routed, the target server MUST have advertised the
Application Identifier (see section 6.1) for instance), the
revision of given message, or
have advertised itself as a relay or proxy agent.

5.3.2 Redirecting requests

When a redirector agent receives a request whose routing entry is set
to REDIRECT, it MUST answer the request with Message-Reject-Answer,
while maintaining the Diameter software module may be reported instead.

6.2.3 Auth-Extension-Id AVP

The Auth-Extension-Id AVP (AVP Code 258) is of type Unsigned32 and is
used Hop-by-Hop Identifier in order to advertise support of the Authentication header, and
Authorization portion of an extension (see Section 6.1). The Auth-

Calhoun et al. expires October December 2001 [Page 30] 38]

Internet-Draft May June 2001

Extension-Id MUST also be present in all Authentication and/or
Authorization messages that are defined in a separate Diameter
specification and have an Extension ID assigned.

6.2.4 Host-IP-Address AVP

The Host-IP-Address

include the Result-Code AVP (AVP Code 257) is of type Address and is used to inform a Diameter peer DIAMETER_REDIRECT_INDICATION. Each of
the sender's IP address. All source
addresses that a Diameter node expects to use servers associated with SCTP [26] MUST be
advertised in the Device-Reboot-Ind message by including a Host-IP-
Address AVP for each address. This AVP MUST ONLY be used in the
Device-Reboot-Ind message.

6.2.5 Supported-Vendor-Id AVP

The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
contains the IANA "SMI Network Management Private Enterprise Codes"
[2] value assigned to a vendor other than the device vendor. This is
used in the Device-Reboot-Ind message routing entry are added in order to inform the peer
that the sender supports a subset separate
Redirect-Host AVP.

+------------------+
| Diameter |
| Redirector Agent |
+------------------+
^ |
1. Request | | 2. MRA +
joe@xyz.com | | Result-Code = DIAMETER_REDIRECT_INDICATION +
| | Redirect-Host AVP(s)
| v
+---------+ 3. Request +----------+
| abc.net |------------->| xyz.net |
| Relay | | Diameter |
| Agent |<-------------| Server |
+---------+ 4. Answer +----------+
Figure 7: Diameter Redirect Server

Redirector agents MAY also include the certificate of the vendor-specific commands
and/or attributes defined by servers in
the vendor identified Redirect-Host AVP(s). These certificates are encapsulated in this AVP.

6.2.6 Product-Name a
CMS-Cert AVP [11].

The Product-Name AVP (AVP Code 269) is receiver of type OctetString, encoded
in the UTF-8 [24] format, and contains the vendor assigned name for MRA message with the product. The Product-Name Result-Code AVP SHOULD remain constant across
firmware revisions for set to
DIAMETER_REDIRECT_INDICATION uses the same product.

6.2.7 Acct-Extension-Id AVP

The Acct-Extension-Id AVP (AVP Code 259) is of type Unsigned32 and is
used hop-by-hop field in order the
Diameter header to advertise support of identify the Accounting portion of an
extension request in the pending message queue
(see Section 6.1). The Acct-Extension-Id MUST also be
present in all Accounting messages 7.3) that are defined in a separate
Diameter specification and have an Extension ID assigned.

7.0 Transport Failure Detection

Given the nature of the Diameter protocol, it is recommended that
transport failures to be detected as soon as possible. Detecting such
failures will minimize redirected. If no transport
connection exists with the occurrence of messages sent to unavailable
servers, resulting in unnecessary delays, new agent, one is created, and will provide better

Calhoun et al. expires October 2001 [Page 31]

Internet-Draft May 2001

failover performance.

In order to pro-actively detect such failures, the Diameter protocol
defines the Device-Watchdog-Request message, which request
is sent directly to an
inactive peer. it.

5.3.3 Relaying and Proxying Requests

A peer relay or proxy agent MUST check for forwarding loops before
forwarding requests. A loop is considered inactive detected if no messages were sent
or received from the peer within server finds its own
address in a Route-Record AVP. When such an event occurs, the current watchdog interval period
(see Section 18.0), and no request messages are pending agent
MUST answer with the
peer.

For implementations that have access Result-Code AVP set to the Retransmission Time-Out
(RTO) value of the underlying transport connection, DIAMETER_LOOP_DETECTED.

A relay or proxy agent MUST append a DWR SHOULD Route-Record AVP that includes
its identity to all requests forwarded. The last Route-Record AVP in
all requests received MUST be
sent once per RTO of validated, by ensuring that connection, plus the watchdog interval
period, with a jittering of +/- 50%.

If the DWR is unanswered, the time until host
encoded in the next DWR AVP is sent MUST be
recalculated after exponentially backing off the RTO portion. When same as the value of peer the DWR's current watchdog interval period reaches message was received
from.

The Hop-by-Hop identifier in the
maximum watchdog interval (Section 18.0), backoff request is not continued, saved, and replaced with
a locally unique value.

Calhoun et al. expires December 2001 [Page 39]

Internet-Draft June 2001

Relay and Proxy agents MAY include the peer Proxy-Info AVP in requests if
it requires access any local state information when the corresponding
response is marked as failed. DWR messages continue received. Alternatively, it MAY simply use local storage
to be sent
(jittered) at the final interval for detection for failover. store state information.

The
current watchdog interval message is returned then forwarded to its starting point when a
DWA is received or the peer resumes activity.

Implementations next hop, as identified in the
Domain Routing Table.

Figure 6 provides an example of message routing using the procedures
listed in these sections.

(Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net)
(Origin-Realm=mno.net) (Origin-Realm=mno.net)
(Destination-Realm=abc.com) (Destination-Realm=abc.com)
(Route-Record=drl.mno.net)
+------+ ------> +------+ ------> +------+
| | (Request) | | (Request) | |
| NAS +-------------------+ DRL +-------------------+ HMS |
| | | | | |
+------+ <------ +------+ <------ +------+
mno.net (Answer) mno.net (Answer) abc.com
(Origin-Host=hms.abc.com) (Origin-Host=hms.abc.com)
(Origin-Realm=abc.com) (Origin-Realm=abc.com)
(Destination-Host=nas.mno.net) (Destination-Host=nas.mno.net)
(Route-Record=drl.mno.net)
Figure 6: Routing of Diameter messages

5.3.4 Relaying and Proxying Answers

A relay or proxy agent MUST only process Answers whose last Route-
Record AVP matches one of its identities. Any answers that do not have access
conform to the RTO SHOULD perform an
Round Trip Time (RTT) measurement for a given peer when a Device-
Watchdog-Answer message is received for a non-backed off DWR. The
fixed RTO base should this rule MUST be replaced by RTT-Multiplier (Section 18.0)
times the measured RTT.

An example of the backoff sequence, excluding jitter, would be:
30+RTO , 30+2*RTO , 30+4*RTO , 30+8*RTO, 60, 60, 60

Note that exponential backoff dropped. The last Route-Record AVP MUST
be performed removed from the message before it is forwarded to the maximum next hop,
which is
reached.

7.1 Device-Watchdog-Request

The Device-Watchdog-Request (DWR), indicated identified by the Command-Code set second to 280 and last Route-Record AVP.

If the last Proxy-Info AVP in the message flags' 'R' bit set, is sent targeted to a peer when no
traffic has been exchanged between two peers as defined in Section
7.0, and no requests are pending with the peer.

Message Format

Calhoun et al. expires October 2001 [Page 32]

Internet-Draft May 2001

<Device-Watchdog-Request> ::= < local
Diameter Header: 280, R>
{ Origin-FQDN }
{ Origin-Realm }
[ Destination-FQDN ]

7.2 Device-Watchdog-Answer

The Device-Watchdog-Answer (DWA), indicated by the Command-Code set
to 280 and server, the message flags' 'A' bit set, is sent as AVP MUST be removed.

If a response to relay or proxy agent receives an answer with a Result-Code AVP
indicating a failure, it MUST NOT modify the Device-Watchdog-Request message. A receiver contents of the DWA AVP. Any
additional local errors detected SHOULD
perform RTT calculation be logged, but not reflected
in the event that the transport RTO
information is not available.

Message Format

<Device-Watchdog-Answer> ::= < Diameter Header: 280, A >
{ Result-Code }
{ Origin-FQDN }
{ Origin-Realm }
{ Destination-FQDN }

7.3 Failover/Failback Procedures

In AVP. If the event that a transport failure is detected agent receives an answer message with
a peer, it is
necessary for all pending request Result-Code AVP indicating success, and indication messages it wishes to be
forwarded modify the AVP
to indicate an alternate server, if possible. This is commonly
referred to as failover.

In order for a Diameter node to perform failover procedures, error, it is
necessary for MUST issue an STR on behalf of the node access
device.

Prior to maintain a pending message queue for a
given peer. When a response is received, forwarding the message is removed from answer, the queue. The agent MUST restore the original

Calhoun et al. expires December 2001 [Page 40]

Internet-Draft June 2001

value of the Diameter header's Hop-by-Hop Identifier field field.

5.3.5 Hiding Network Topology

A Relay or Proxy agent routing messages outside of their
administrative domain MAY be used need to match the
corresponding response with hide the queued request.

When a transport failure internal Diameter
topology. This is detected, done by removing all messages Route-Record AVPs in a
request, and later adding them back into the corresponding answer, in
the queue are
sent same order. Such agents MUST take care to an alternate server, if possible. An example not assume that the
absence of a case where
it any Route-Record AVPs implies the message is not possible for forward local
comsumption.

5.4 Origin-Host AVP

The Origin-Host AVP (AVP Code 264) is of type OctetString, encoded in
the message UTF-8 [24] format, according to an alternate server is
when the message has a fixed destination, Diameter identity rules
defined in section 2.7, and MUST be present in all Diameter messages.
This AVP identifies the unavailable peer is endpoint which originated the message's final destination (see Destination-FQDN AVP). Such an
error requires Diameter
message, i.e. the access device, home server, or broker. Relay agents
MUST NOT modify this AVP.

Note that the server return an DSI with the DSI-Event Origin-Host AVP
set to DIAMETER_UNABLE_TO_DELIVER.

It is important may resolve to note that multiple identical request or responses
MAY more than one address as
the Diameter peer may support more than one address.

This AVP SHOULD be received placed as a result of a failover. close to the Diameter header as
possible.

5.5 Origin-Realm AVP

The End-to-End Identifier
field Origin-Realm AVP (AVP Code 296) is of type OctetString, encoded
in the UTF-8 [24] format. This AVP contains the Realm of the
originator of any Diameter header message and MUST be used to identify duplicate
messages.

Calhoun et al. expires October 2001 [Page 33]

Internet-Draft May 2001

As described in section 2.1, a connection request should be
periodically attempted with the failed peer present in order to re-establish
the transport connection. Once a connection has been successfully
established, all
messages can once again

This AVP SHOULD be forwarded placed as close to the peer. This Diameter header as
possible.

5.6 Destination-Host AVP

The Destination-Host AVP (AVP Code 293) is commonly referred of type OctetString,
encoded in the UTF-8 [24] format, according to as failback.

8.0 Peer State Machine

This the Diameter identity
rules defined in section contains a finite state machine, that 2.7. This AVP MUST be observed
by present in all Diameter implementations. Each Diameter node MUST follow the
state machine described below when communicating with each peer.
Multiple actions are separated by commas, and may continue on
succeeding lines as space requires. Similarly, state and next state
may also span multiple lines as space requires.

There may be at most one transport connection between any two peers
over which Diameter messages may
unsolicited agent initiated messages, MAY be passed. This state machine present in request
messages, and MUST be present in Answer messages. The value of the

Calhoun et al. expires December 2001 [Page 41]

Internet-Draft June 2001

Destination-Host AVP is
intended set to handle both the simple case, value of the Origin-Host AVP found
in which one peer initiates a connection message from the intended target host.

This AVP SHOULD be placed as close to the other, Diameter header as
possible.

5.7 Destination-Realm AVP

The Destination-Realm AVP (AVP Code 283) is of type OctetString,
encoded in the UTF-8 [24] format, and contains the complex case, realm the message
is to be routed to. The Destination-Realm AVP MUST NOT be present in which each peer
simultaneously initiates
Answer messages. Diameter Clients insert the realm portion of the
User-Name AVP. Diameter servers initiating a connection to request message use the other. In
value of the complex
case, an election occurs to determine which transport connection will
survive.

I- is used to represent Origin-Realm AVP from a previous message received from
the initiator (connecting) connection, while intended target host (unless it is known a priori). When present,
the R- Destination-Realm AVP is used to represent perform message routing
decisions.

Request messages whose ABNF does not list the responder (listening) connection. The
lack of Destination-Realm AVP
as a prefix indicates that mandatory AVP are inherently non-routable messages.

This AVP SHOULD be placed as close to the event or action Diameter header as
possible.

5.8 Routing AVPs

The AVPs defined in this section are Diameter AVPs used for routing
purposes. These AVPs change as Diameter messages are processed by
agents, and therefore MUST NOT be protected using the Diameter CMS
Security application [11].

5.8.1 Route-Record AVP

The Route-Record AVP (AVP Code 282) is the same
regardless of type OctetString, encoded
in the connection on which UTF-8 [24] format, according to the event occurred. Diameter identity rules
defined in section 2.7. The stable states that a state machine may be identity added in are Closed, I-Open
and R-Open; all other states are intermediate. Note that I-Open and
R-Open are equivalent except for whether the initiator or responder
transport connection is used for communication.

A DRI message is always sent on this AVP MUST be the responder connection immediately
after accepting
same as the connection request. The non-elected connection
will close down. All subsequent messages are identity sent on the elected
connection.

The state machine constrains only in the behavior Origin-Host of a Diameter
implementation as seen by Diameter peers through events on the wire.
Any implementation that produces equivalent results Capabilities-
Exchange-Request message.

5.8.2 Proxy-Info AVP

The Proxy-Info AVP (AVP Code = 284) is considered
compliant.

state event action next state
-----------------------------------------------------------------
Closed Start I-Snd-Conn-Req Wait-Conn-Ack

Calhoun et al. expires October 2001 [Page 34]

Internet-Draft May 2001

R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-R-DRI

Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-DRI Wait-I-DRI
I-Rcv-Conn-Nack Cleanup Closed
R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-Conn-Ack/
Wait-R-DRI
Timeout Error Closed

Wait-I-DRI I-Rcv-DRI Process-DRI I-Open
R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-R-DRI/
Elect
I-Peer-Disc I-Disc Closed
Timeout Error Closed

Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-DRI Wait-R-DRI/
Wait-R-DRI Elect
I-Rcv-Conn-Nack Cleanup Wait-R-DRI
R-Rcv-DRI Process-DRI Wait-Conn-Ack/
Elect
Timeout Error Closed

Wait-R-DRI/ R-Rcv-DRI Process-DRI, Wait-Returns
Elect Elect
I-Peer-Disc I-Disc Wait-R-DRI
Timeout Error Closed

Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-DRI,Elect Wait-Returns
Elect I-Rcv-Conn-Nack R-Snd-DRI R-Open
R-Peer-Disc R-Disc Wait-Conn-Ack-2
Timeout Error Closed

Wait-Returns Win-Election I-Disc,R-Snd-DRI R-Open
I-Peer-Disc I-Disc,R-Snd-DRI R-Open
I-Rcv-DRI R-Disc I-Open
R-Peer-Disc R-Disc Wait-I-DRI-2
Timeout Error Closed

Wait-Conn-Ack-2 I-Rcv-Conn-Ack I-Snd-DRI Wait-I-DRI-2
I-Rcv-Conn-Nack Cleanup Closed
R-Rcv-Conn-Req R-Snd-Conn-Nack Wait-Conn-Ack-2
Timeout Error Closed

Wait-I-DRI-2 I-Rcv-DRI Process-DRI I-Open
I-Peer-Disc I-Disc Closed
R-Rcv-Conn-Req R-Snd-Conn-Nack Wait-I-DRI-2
Timeout Error Closed

Wait-R-DRI R-Rcv-DRI Process_DRI, R-Open of type Grouped. The Grouped
Data field has the following ABNF grammar:

Calhoun et al. expires October December 2001 [Page 35] 42]

Internet-Draft May June 2001

R-Snd-DRI
Timeout Error Closed

R-Open Send-Message R-Snd-Non-DRI R-Open
R-Rcv-Non-DRI Process R-Open
R-WatchDog-Timer R-Snd-DWR R-Open
R-Rcv-DWA Process-DWA R-Open
Stop R-Snd-Disc Closed
R-Peer-Disc R-Disc Closed
R-Rcv-DRI Error Closed

I-Open Send-Message I-Snd-Non-DRI I-Open
I-Rcv-Non-DRI Process I-Open
I-WatchDog-Timer I-Snd-DWR I-Open
I-Rcv-DWA Process-DWA I-Open
Stop I-Disc Closed
I-Peer-Disc I-Disc Closed
I-Rcv-DRI Error Closed
R-Rcv-Conn-Req R-Snd-Conn-Nack I-Open

8.1 States

Following

Proxy-Info ::= < AVP Header: 284 >
{ Proxy-Host }
{ Proxy-State }
* [ AVP ]

5.8.3 Proxy-Host AVP

The Proxy-Host AVP (AVP Code = 280) is a more detailed description of each automaton state.

Closed A peer is initially type OctetString, encoded
in the closed state, UTF-8 [24] format, according to the Diameter identity rules
defined in section 2.7. This AVP contains the identity of the host
that added the Proxy-Info AVP.

5.8.4 Proxy-State AVP

The Proxy-State AVP (AVP Code = 33) is of type OctetString, and no
transport connection exists with
contains state local information, and MUST be treated as opaque data.

5.9 Redirect-Host AVP

The Redirect-Host AVP (AVP Code 292) is of type OctetString, encoded
in the peer.

Wait-Conn-Ack A UTF-8 [24] format, according to the Diameter identity rules
defined in section 2.7. This AVP MUST be present in Message-Reject-
Answer messages that include the Result-Code AVP set to
DIAMETER_REDIRECT_INDICATION.

Upon receiving the above, the receiving Diameter node SHOULD forward
the request directly to the host identified in this AVP.

6.0 Capabilities Exchange

When two Diameter peers establish a transport connection has been initiated with connection, they MUST
exchange the
peer, Device Reboot messages, as specified in the peer state
machine (see section 8.0). This message has two purposes. First it
allows a peer's identity to be discovered, and an acknowledgement is pending.

Wait-I-DRI The local Diameter node is waiting allows for
capabilities exchange, such as the peer to
issue a DRI.

Wait-Conn-Ack/Wait-R-DRI
A transport connection indication from supported protocol version number,
the peer was
received, while a transport connection has already
been locally initiated.

Wait-R-DRI/Elect
Two transport connections supported Diameter applications, etc.

The receiver only issues commands to its peers that have been established
with advertised
support for the peer, and a DRI is pending on Diameter application that defines the
responder connection.

Wait-Conn-Ack/Elect command. A transport connection exists on
Diameter node MUST cache the responder
connection, while an acknowledgment has yet supported applications in order to be
received on the initiator connection.
ensure that unrecognized commands and/or AVPs are not unnecessarily
sent to a peer.

A receiver of a Capabilities-Exchange-Req message which does not have

Calhoun et al. expires October December 2001 [Page 36] 43]

Internet-Draft May June 2001

Wait-Returns Multiple transport connections caused an election
to occur.

Wait-Conn-Ack-2
While an acknowledgement to

any applications in common with the sender MUST return a locally initiated
Capabilities-Exchange-Answer with the Result-Code AVP set to
DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport connection hasn't been received, an
election has failed
layer connection.

The Capabilities-Exchange-Request and Capabilities-Exchange-Answer
messages MUST NOT be proxied, or redirected.

Since the initiator connection
will CER/CEA messages cannot be proxied, it is still possible
that an upstream proxy receives a message for which it has no
available peers to handle the application that corresponds to the
Command-Code. In such instances, the Message-Reject-Answer message is
used between (see Section 9.2.1) to inform the peers.

Wait-I-DRI-2 Following downstream to take action
(e.g. re-routing request to an election, alternate peer).

With the initiator connection
won, and exception of the Capabilities-Exchange-Request message, a
message of type Request that includes the Auth-Application-Id or
Acct-Application-Id AVPs, or a DRI has yet to message with an application-specific
command code, MAY only be received by the peer.

Wait-R-DRI A transport connection indication forwarded to a host that has been received
from explicitly
advertised support for the peer, and a DRI application (or has yet to be received by advertised the peer.

R-Open Relay
Application Identifier).

6.1 Application Identifiers

Each Diameter application MUST have an IANA assigned Application
Identifier (see section 15.3). The responder connection will be used to
communicate with the peer.

I-Open base protocol does not require an
application Identifier since its support is mandatory.

Application Identifiers are communicated via two separate AVPs;
Auth-Application-Id and Acct-Application-Id. The initiator connection will be Auth-Application-Id
AVP is used to communicate with the peer.

8.2 Events

Transitions and actions in the automaton are caused by events. In
this section we will ignore support for the -I authentication and -R prefix, since the actual
event would be identical, but would occur on one
authorization portion of two possible
connections.

Start an application. The Diameter application has signaled that a
connection should be initiated with Acct-Application-Id AVP,
on the peer.

Rcv-Conn-Req A transport connection indication from other hand, communicates support for the peer has
been received.

Rcv-Conn-Ack A positive acknowledgement was received to accounting portion of
an application.

This separation of AVPs allows a
locally initiated transport connection.

Rcv-Conn-Nack A negative acknowledgement was received server to a
locally initiated transport connection.

Timeout An application-defined timer has expired while
waiting communicate that it is
willing to accept only accounting messages for some event.

Rcv-DRI A DRI message from the peer was received.

Peer-Disc A disconnection indication from a given application.

The following Application Identifier values are defined:

NASREQ 1 [7]
End-to-End Security 2 [11]
Mobile-IP 4 [10]
Relay 0xffffffff

Relay and redirect agents MUST advertise the peer was Proxy application
identifier, while all other Diameter nodes MUST advertise locally

Calhoun et al. expires October December 2001 [Page 37] 44]

Internet-Draft May June 2001

received.

Win-Election An election was held, and the local node was the
winner.

Send-Message A Non-DRI message is to be sent.

Rcv-Non-DRI A Non-DRI message was received.

WatchDog-Timer

supported applications. The Watchdog timer expired, indicating that receiver of a DWR Device Reboot message is to be sent to
advertising Relay service MUST assume that the peer.

Rcv-DWA A DWA message was received.

Stop The sender supports all
current and future applications.

Diameter application has signaled relay and proxy agents are responsible for finding a
downstream server that supports the application of a
connection should particular
message. If none can be terminated (e.g., on system
shutdown).

8.3 Actions

Actions in found, a MRA message is returned with the automaton are caused
Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

6.2 Capabilities-Exchange-Request

The Capabilities-Exchange-Request (CER), indicated by events the Command-
Code set to 257 and typically indicate the transmission of packets and/or an action Command Flags' 'R' bit set, is sent to be taken on inform
a peer that a reboot has occurred.

When Diameter is run over SCTP [26], which allows for connections to
span multiple interfaces, hence multiple IP addresses, the
connection. In this section we will ignore
Capabilities-Exchange-Request message MUST contain one Host-IP-
Address AVP for each potential IP address that MAY be locally used
when transmitting Diameter messages.

Message Format

<Capabilities-Exchange-Req> ::= < Diameter Header: 257, REQUEST >
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Acct-Application-Id ]
[ Destination-Host ]
[ Firmware-Revision ]
* [ AVP ]

6.3 Capabilities-Exchange-Answer

The Capabilities-Exchange-Request (CEA), indicated by the -I Command-
Code set to 257 and -R prefix,
since the actual action would be identical, but would occur on one of
two possible connections.

Snd-Conn-Req A transport connection is initiated with the peer.

Snd-Conn-Ack an acknowledgement Command Flags' 'R' bit cleared, is sent in
response to a connect
request, confirming that the transport layer
connection is open.

Snd-Conn-Nack A negative acknowledgement CER message.

When Diameter is sent in response run over SCTP [26], which allows for connections to a
connect request, indicating that
span multiple interfaces, hence multiple IP addresses, the request was
refused.

Snd-DRI A DRI
Capabilities-Exchange-Answer message is sent to the peer.

Cleanup If necessary, the connection is shutdown, and any
local resources are freed.

Error The transport layer connection is disconnected,
either politely or abortively, in response to an
error condition. Local resources are freed.

Process-DRI A received DRI is processed. MUST contain one Host-IP-Address

Calhoun et al. expires October December 2001 [Page 38] 45]

Internet-Draft May June 2001

Disc The transport layer connection is disconnected, and
local resources are freed.

Elect An election occurs (see Section 8.4

AVP for more
information).

Snd-Non-DRI A non-DRI message is sent.

Snd-DWR A DWR message is sent.

Process-DWA The DWA message is serviced.

Process A non-DRI each potential IP address that MAY be locally used when
transmitting Diameter message is serviced.

8.4 The Election Process messages.

Message Format

<Capabilities-Exchange-Answer> ::= < Diameter Header: 257 >
{ Result-Code AVP }
{ Origin-Host }
{ Origin-Realm }
1* { Host-IP-Address }
{ Vendor-Id }
{ Product-Name }
[ Origin-State-Id ]
* [ Supported-Vendor-Id ]
* [ Auth-Application-Id ]
* [ Acct-Application-Id ]
[ Destination-Host ]
[ Firmware-Revision ]
* [ AVP ]

6.4 Vendor-Id AVP

The election Vendor-Id AVP (AVP Code 266) is performed on of type Unsigned32 and contains
the responder. The responder compares IANA "SMI Network Management Private Enterprise Codes" [2] value
assigned to the Origin-FQDN received in vendor of the DRI sent by its peer Diameter device.

In combination with its own
Origin-FQDN (which it may or the Supported-Vendor-Id AVP (section 6.8), this
MAY be used in order to know which vendor specific attributes may not have actually sent). The
transport layer connection with be
sent to the higher peer. It is also envisioned that the combination of the
Vendor-Id, Product-Name (section 6.9) and the Firmware-Revision
(section 6.5) AVPs MAY provide very useful debugging information.

A Vendor-Id value of Origin-FQDN is zero in the one CER or CEA messages is reserved and
indicates that survives. The comparison proceeds by considering the
shorter OctetString Diameter peer is in the experimental or concept
stage and that an IANA Private Enterprise Number has yet to be null-padded
obtained by the implementor.

6.5 Firmware-Revision AVP

The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is
used to inform a Diameter peer of the length firmware revision of the longer,
then performing an octet by octet unsigned comparison with
issuing device.

For devices that do not have a firmware revision (general purpose
computers running Diameter software modules, for instance), the first
octet being most significant. Hanging octets are assumed
revision of the Diameter software module may be reported instead.

Calhoun et al. expires December 2001 [Page 46]

Internet-Draft June 2001

6.6 Auth-Application-Id AVP

The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and
is used in order to have
value 0x80, but dimpled octets are ignored.

9.0 Error Handling

This section will specify advertise support of the how Diameter error handling occurs.
There are two separate error types Authentication and
Authorization portion of an application (see Section 6.1). The Auth-
Application-Id MUST also be present in all Authentication and/or
Authorization messages that are considered; end-to-end
and hop-by-hop.

9.1 End-to-End Error Signaling

An End-to-End error occurs when defined in a separate Diameter entity sends a message
specification and
either have an intermediate proxy, or the home server, wishes Application ID assigned.

This AVP SHOULD be placed as close to return a
failure.

When a diameter message of type Request is received, and an error is
identified, the 'A' bit Diameter header as
possible.

6.7 Host-IP-Address AVP

The Host-IP-Address AVP (AVP Code 257) is set of type Address and the Result-Code AVP is added used
to inform a Diameter peer of the message. The sender MAY also include additional AVPs sender's IP address. All source
addresses that help
identify the error condition. Certain Result-Code values require a Diameter node expects to use with SCTP [26] MUST be
advertised in the
presence of additional AVPs.

When CER and CEA messages by including a diameter message Host-IP-Address
AVP for each address. This AVP MUST ONLY be used in the CER and CEA
messages.

6.8 Supported-Vendor-Id AVP

The Supported-Vendor-Id AVP (AVP Code 265) is of type Indication is received, Unsigned32 and an error

Calhoun et al. expires October 2001 [Page 39]

Internet-Draft May 2001

is identified, the above procedures are followed except
contains the 'F' bit
is set, as opposed IANA "SMI Network Management Private Enterprise Codes"
[2] value assigned to a vendor other than the 'A' bit.

In the event that an unrecognized AVP device vendor. This is received,
used in the CER and it is marked
as Mandatory (the 'M' bit is set), CEA messages in order to inform the Result-Code AVP is added with peer that the value DIAMETER_AVP_UNSUPPORTED, as is
sender supports a subset of the Failed-AVP AVP,
containing vendor-specific commands and/or AVPs
defined by the offending vendor identified in this AVP.

Should an

6.9 Product-Name AVP be received with an unrecognized value, the Result-Code

The Product-Name AVP (AVP Code 269) is added with its value set to DIAMETER_INVALID_AVP_VALUE, as is of type OctetString, encoded
in the Failed-AVP AVP, containing UTF-8 [24] format, and contains the offending AVP. vendor assigned name for
the product. The Result-Code Product-Name AVP lists many additional error conditions that may
occur.

9.1.1 Result-Code SHOULD remain constant across
firmware revisions for the same product.

6.10 Acct-Application-Id AVP

The Result-Code Acct-application-Id AVP (AVP Code 268) 259) is of type Unsigned32 and
indicates whether a particular request was completed successfully or
whether an error occurred. All Diameter messages of type *-Answer, as
well as *-Ind messages with the 'F' bit set, MUST include one
Result-Code AVP. A non-successful Result-Code AVP (one containing a
non 2001 value) MUST include the Error-Reporting-FQDN AVP.

The Result-Code data field contains an IANA-managed 32-bit address
space representing errors (see section 16.4). Diameter provides the
following classes of errors, all identified by the thousands digit:
- 1xxx (Informational)
- 2xxx (Success)
- 4xxx (Transient Failures)
- 5xxx (Permanent Failure)

A non-recognize class (one whose first digit
is not defined in this
section) MUST be handled as a permanent failure.

9.1.1.1 Informational

Errors that fall within the Informational category are used to inform
a requester that the request cannot be immediately satisfied and a
further response will be issued in order to advertise support of the near future. There are
currently no errors that fall within this class.

9.1.1.2 Success

Errors Accounting portion of an
application (see Section 6.1). The Acct-Application-Id MUST also be
present in all Accounting messages that fall within the Success category are used to inform defined in a separate
Diameter specification and have an Application ID assigned.

Calhoun et al. expires October December 2001 [Page 40] 47]

Internet-Draft May 2001

peer that a request has been successfully completed.

DIAMETER_SUCCESS June 2001
The Request was successfully completed.

9.1.1.3 Transient Failures

Errors that fall within

This AVP SHOULD be placed as close to the transient failures category are Diameter header as
possible.

6.11 Vendor-Specific-Application-Id AVP

The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
Grouped and is used to
inform advertise support of a peer that vendor-specific
Diameter Application. Either the request could not be satisfied at Auth-Application-Id or the time it
was received, but Acct-
Application-Id AVP MAY be able to satisfy present. Both AVPs MAY be present if they
both contain the request same value.

This AVP MUST also be present in all vendor-specific commands defined
in the future.

DIAMETER_AUTHENTICATION_REJECTED 4001
The authentication process for the user failed, most likely due vendor-specific application.

This AVP SHOULD be placed as close to an invalid password used by the user. Further attempts MUST
only be tried after prompting Diameter header as
possible.

AVP Format

<Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ]
0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id }

7.0 Transport Failure Detection

Given the user for a new password.

DIAMETER_END_2_END_SECURITY 4002
A proxy has detected nature of the Diameter protocol, it is recommended that end-to-end security has been applied
to portions
transport failures be detected as soon as possible. Detecting such
failures will minimize the occurrence of messages sent to unavailable
servers, resulting in unnecessary delays, and will provide better
failover performance. The Device-Watchdog-Request and Device-
Watchdog-Answer messages, defined in this section, are used to pro-
actively detect transport failures.

The watchdog behavior is controlled by the Diameter message, Tw timer, which ranges
between 30 and the proxy does not
allow this security mode since it needs 60 seconds. In order to alter avoid synchronization
behaviors that can occur with fixed timers among distributed systems,
each time the message watchdog interval is calculated with a jitter by
applying some local policies.
DIAMETER_OUT_OF_SPACE 4003
A Diameter node received using
the accounting request but was unable
to commit it to stable storage due Tw value (which defaults to 30 seconds) and randomly adding or
subtracting a temporary lack of
space.

9.1.1.4 Permanent Failures

Errors that fall within the permanent failures category are used random value drawn between 0.5 and 2 seconds.
Alternative calculations to
inform the peer that the request failed, create jitter MAY be used. These MUST be
pseudo-random and should not be attempted
again.

DIAMETER_USER_UNKNOWN 5001
A request was received for cyclic.

When a user that response is unknown, therefore
authentication and/or authorization failed.

DIAMETER_AVP_UNSUPPORTED 5002
The peer received a message that contained an AVP that received, Tw is not
recognized or supported reset. Receiving a watchdog from a
peer constitutes activity, and was marked with the Mandatory bit.
A Diameter message with this error MUST contain one or more
Failed-AVP AVP containing Tw should be reset. On sending a
message, if the AVPs that caused queue is empty, then Tw is reset. If the failure.

DIAMETER_UNKNOWN_SESSION_ID 5003
The request or response contained an unknown Session-Id.

DIAMETER_AUTHORIZATION_REJECTED 5004 watchdog

Calhoun et al. expires October December 2001 [Page 41] 48]

Internet-Draft May 2001

A request was received for which the user could not be
authorized. This error could occur if the service requested is
not permitted to the user.

DIAMETER_INVALID_AVP_VALUE 5005
The request contained an AVP with an invalid value in its data
portion. A Diameter message indicating this error MUST include June 2001

timer expires and the offending AVPs within queue is empty, then a Failed-AVP AVP.

DIAMETER_MISSING_AVP 5006
The request did not contain an AVP that watchdog packet is required sent.

7.1 Device-Watchdog-Request

The Device-Watchdog-Request (DWR), indicated by the Command-Code set
to 280 and the Command Code definition. If this value Flags' 'R' bit set, is sent to a peer when no
traffic has been exchanged between two peers as defined in Section
7.0, and no requests are pending with the Result-
Code AVP, peer.

Message Format

<Device-Watchdog-Request> ::= < Diameter Header: 280, REQUEST >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }

7.2 Device-Watchdog-Answer

The Device-Watchdog-Answer (DWA), indicated by the Command-Code set
to 280 and the Command Flags' 'R' bit cleared, is sent as a Failed-AVP AVP SHOULD be included in response
to the Device-Watchdog-Request message.
The data portion A receiver of the Failed-AVP MUST only contain DWA SHOULD
perform RTT calculation in the AVP
Code of event that the missing AVP.

DIAMETER_INVALID_CMS_DATA 5007
The Request did transport RTO
information is not contain available.

Message Format

<Device-Watchdog-Answer> ::= < Diameter Header: 280 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }

7.3 Failover/Failback Procedures

In the event that a valid CMS-Data [11] AVP.

DIAMETER_LOOP_DETECTED 5008
A Proxy or Redirect server transport failure is detected with a loop while trying peer, it is
necessary for all pending request messages to get be forwarded to an
alternate agent, if possible. This is commonly referred to as
failover.

In order for a Diameter node to perform failover procedures, it is
necessary for the message node to maintain a pending message queue for a
given peer. When an answer message is received, the Home Diameter server. corresponding
request is removed from the queue. The message Hop-by-Hop Identifier field
MAY be used to match the answer with the queued request.

Calhoun et al. expires December 2001 [Page 49]

Internet-Draft June 2001

When a transport failure is detected, all messages in the queue are
sent to an alternate peer, agent, if one is available, but the peer
reporting the error has identified possible. An example of a configuration problem.

DIAMETER_AUTHORIZATION_FAILED 5009
A request was received case where
it is not possible for which forward the user could not be
authorized at this time. This error could occur message to an alternate server is
when the user message has already expended allowed resources, or is only permitted to
access services within a time period.

DIAMETER_CONTRADICTING_AVPS 5010
The Home Diameter server has detected AVPs in the request that
contradicted each other, fixed destination, and is not willing to provide service
to the user. One or more Failed-AVP AVPs MUST be present,
containing unavailable peer is
the AVPs that contradicted each other.

DIAMETER_AVP_NOT_ALLOWED 5011
A message was received with message's final destination (see Destination-Host AVP). Such an AVP
error requires that MUST NOT be present.
The Failed-AVP AVP MUST be included and contain the AVP Code of the offending AVP.

DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5012
A message was received that included agent return an AVP that appeared more
often than permitted in MRA with the message definition. The Failed-AVP Result-Code AVP MUST
set to DIAMETER_UNABLE_TO_DELIVER.

It is important to note that multiple identical request or answer MAY
be included and contain the AVP Code received as a result of the offending
AVP.

Calhoun et al. expires October 2001 [Page 42]

Internet-Draft May 2001

DIAMETER_VENDOR_ID_UNSUPPORTED 5013 a failover. The Home Diameter server has detected vendor-specific AVPs End-to-End Identifier
field in the message, and Diameter header along with the vendor dictionary is not supported. One or
more Failed-AVP Origin-Host AVP MUST be present, containing the offending AVPs.

9.1.2 Error-Message AVP

The Error-Message AVP (AVP Code 281) is of type OctetString. It is
used to identify duplicate messages.

As described in section 2.1, a
human readable UTF-8 character encoded string. It MAY accompany connection request should be
periodically attempted with the failed peer in order to re-establish
the transport connection. Once a
Result-Code AVP connection has been successfully
established, messages can once again be forwarded to the peer. This
is commonly referred to as failback.

8.0 Peer State Machine

This section contains a human readable error message. The Error-Message
AVP finite state machine, that MUST be observed
by all Diameter implementations. Each Diameter node MUST follow the
state machine described below when communicating with each peer.
Multiple actions are separated by commas, and may continue on
succeeding lines as space requires. Similarly, state and next state
may also span multiple lines as space requires.

There may be at most one transport connection between any two peers
over which Diameter messages may be passed. This state machine is not
intended to be useful handle both the simple case, in real-time, which one peer initiates
a connection to the other, and SHOULD NOT be
expected the complex case, in which each peer
simultaneously initiates a connection to be parsed by network entities.

9.1.3 Error-Reporting-FQDN AVP

The Error-Reporting-FQDN AVP (AVP Code 294) the other. In the complex
case, an election occurs to determine which transport connection will
survive.

I- is used to represent the initiator (connecting) connection, while
the R- is used to represent the responder (listening) connection. The
lack of type OctetString,
encoded in a prefix indicates that the UTF-8 [24] format. This AVP contains event or action is the FQDN same
regardless of the
Diameter host that set connection on which the Result-Code AVP to event occurred.

The stable states that a value other than 2001
(Success). This AVP is intended to state machine may be used for troubleshooting
purposes, in are Closed, I-Open
and MUST be set when the Result-Code AVP indicates a
failure.

9.2 Hop-by-Hop Error Handling
There R-Open; all other states are many instances where error conditions occur on a Diameter
node, intermediate. Note that needs to be signaled to the downstream server, I-Open and not
necessarily to the Diameter client. Examples of such error conditions
R-Open are inability to forward a equivalent except for whether the initiator or responder
transport connection is used for communication.

A CER message to a particular domain, etc. In
these cases, returning is always sent on the error back to initiating connection immediately

Calhoun et al. expires December 2001 [Page 50]

Internet-Draft June 2001

after the Diameter client connection request is successfully completed. The non-
elected connection will close down. All subsequent messages are sent
on the elected connection.

The state machine constrains only cause delay, and perhaps confusion in roaming networks.

Therefore, when such errors occur, it is necessary for the error to
be handled behavior of a Diameter
implementation as seen by Diameter peers through events on the downstream next hop, and some local wire.
Any implementation that produces equivalent results is considered
compliant.

state event action be taken
to rectify the problem, such as forwarding to a different next hop. state
-----------------------------------------------------------------
Closed Start I-Snd-Conn-Req Wait-Conn-Ack
R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-R-CER

Wait-Conn-Ack I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA
I-Rcv-Conn-Nack Cleanup Closed
R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-Conn-Ack/
Wait-R-CER
Timeout Error Closed

Wait-I-CEA I-Rcv-CEA Process-CEA I-Open
R-Rcv-Conn-Req R-Snd-Conn-Ack Wait-R-CER/
Elect
I-Peer-Disc I-Disc Closed
Timeout Error Closed

Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER Wait-R-CER/
Wait-R-CER Elect
I-Rcv-Conn-Nack Cleanup Wait-R-CER
R-Rcv-CER Process-CER Wait-Conn-Ack/
Elect
Timeout Error Closed

Wait-R-CER/ R-Rcv-CER Process-CER, Wait-Returns
Elect Elect
I-Peer-Disc I-Disc Wait-R-CER
Timeout Error Closed

Wait-Conn-Ack/ I-Rcv-Conn-Ack I-Snd-CER,Elect Wait-Returns
Elect I-Rcv-Conn-Nack R-Snd-CEA R-Open
R-Peer-Disc R-Disc Wait-Conn-Ack-2
Timeout Error Closed

Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open
I-Peer-Disc I-Disc,R-Snd-CEA R-Open
I-Rcv-CEA R-Disc I-Open
R-Peer-Disc R-Disc Wait-I-CEA-2
Timeout Error Closed

Calhoun et al. expires October December 2001 [Page 43] 51]

Internet-Draft May June 2001

Request +--------+ Link Broken
+-------------------------->|Diameter|----///----+
| +---------------------| | v
+-----+---+ | DSI | Server | +--------+
|Diameter |<-+ (Unable to Forward) +--------+ |Diameter|
|Client or| | |
| Server |--+ +--------+ | Server |
+---------+ | Request |Diameter| +--------+
+-------------------->| | ^
| Server |-----------+
+--------+
Figure 1 - Example of Per-Hop

Wait-Conn-Ack-2 I-Rcv-Conn-Ack I-Snd-CER Wait-I-CEA-2
I-Rcv-Conn-Nack Cleanup Closed
R-Rcv-Conn-Req R-Disc Wait-Conn-Ack-2
Timeout Error Condition

If a message Closed

Wait-I-CEA-2 I-Rcv-CEA Process-CEA I-Open
I-Peer-Disc I-Disc Closed
R-Rcv-Conn-Req R-Disc Wait-I-CEA-2
Timeout Error Closed

Wait-R-CER R-Rcv-CER Process_CER, R-Open
R-Snd-CEA
Timeout Error Closed

8.1 States

Following is received with an unrecognized Command-Code, an DSI
message a more detailed description of each automaton state.

Closed A peer is returned with the DSI-Event AVP containing the value
DIAMETER_COMMAND_UNSUPPORTED.

9.2.1 Device-Status-Ind

The Device-Status-Ind (DSI), indicated by initially in the Command-Code set to 282 closed state, and no
transport connection exists with the message flags' 'I' bit set, is sent to inform a peer that an
event has occurred. peer.

Wait-Conn-Ack A Failed Indication would contain transport connection has been initiated with the same
Command-Code, but would require that only be 'F' bit be set.

When a
peer, and an acknowledgement is pending.

Wait-I-CEA The local Diameter node issues a DSI message downstream, is waiting for the target peer
MUST attempt to rectify the problem, or
issue a similar message
downstream. The Device-Status-Ind message MUST NOT be proxied, but
MAY be forwarded, as long as the Origin-FQDN and Origin-Realm AVPs
are replaced to include the local node's identity.

The Device-Status-Ind message MUST contain the same Hop-by-Hop
Identifier value in the header as the message which motivated sending
the DSI. If DRI.

Wait-Conn-Ack/Wait-R-CER
A transport connection indication from the Session-Id AVP peer was present in the original message,
the same AVP MUST be present in the DSI.

Message Format

<Device-Status-Ind> ::= < Diameter Header: 282, I >
{ Origin-FQDN }
{ Origin-Realm }
{ DSI-Event }
[ Destination-FQDN ]
[ Session-Id ]
* [ AVP ]
received, while a transport connection has already

Calhoun et al. expires October December 2001 [Page 44] 52]

Internet-Draft May June 2001

9.2.2 DSI-Event AVP

The DSI-Event AVP (AVP Code 297) is of type Unsigned32

been locally initiated.

Wait-R-CER/Elect
Two transport connections have been established
with the peer, and indicates
that an event occurred which requires attention from a Diameter peer.
The DSI-Event contains an IANA-managed 32-bit address space
representing events (see section 16.5). Diameter provides the
following classes of event notification, all identified by DRI is pending on the
thousands digit:
- 1xxx (Informational Events)
- 3xxx (Redirect Notification)
- 4xxx (Transient Failure Events)
- 5xxx (Permanent Failure Events)
responder connection.

Wait-Conn-Ack/Elect
A non-recognize class (one whose first digit is not defined in this
section) MUST be handled as a permanent failure.

9.2.2.1 Informational Events

Events that fall within transport connection exists on the responder
connection, while an acknowledgment has yet to be
received on the Informational category are used initiator connection.

Wait-Returns Multiple transport connections caused an election
to occur.

Wait-Conn-Ack-2
While an acknowledgement to inform
a peer that a request cannot locally initiated
transport connection hasn't been received, an
election has failed and the initiator connection
will be immediately satisfied, used between the peers.

Wait-I-CEA-2 Following an election, the initiator connection
won, and a further
response will DRI has yet to be issued in received by the near future.

DIAMETER_STILL_WORKING 1001 peer.

Wait-R-CER A request's Max-Wait-Time transport connection indication has expired, and been received
from the request is still
being serviced. This event MAY be sent prior peer, and a DRI has yet to be received by
the Max-Wait-
Time expiration, peer.

R-Open The responder connection will be used to inform the peer that
communicate with the request is not
expected to peer.

I-Open The initiator connection will be serviced in the allotted time, but the request
is not being abandoned. It is important used to note that receiving
this event will result in another Diameter message being
received
communicate with the same Hop-by-Hop peer.

8.2 Events

Transitions and End-to-End identifiers.

9.2.2.2 Redirect Event

Errors that fall within actions in the Redirect Event category automaton are used to
inform a peer that caused by events. In
this section we will ignore the request cannot be satisfied locally -I and should
instead be forwarded to another server.

DIAMETER_REDIRECT_INDICATION 3001
A proxy or redirect server has determined that -R prefix, since the request
could not actual
event would be satisfied locally and the initiator identical, but would occur on one of the request two possible
connections.

Start The Diameter application has signaled that a
connection should direct be initiated with the request directly to peer.

Rcv-Conn-Req A transport connection indication from the server, whose contact
information peer has
been added to the response.

9.2.2.3 Transient Failure Events received.

Calhoun et al. expires October December 2001 [Page 45] 53]

Internet-Draft May June 2001

Errors that fall within the transient failures category are used

Rcv-Conn-Ack A positive acknowledgement was received to a
locally initiated transport connection.

Rcv-Conn-Nack A negative acknowledgement was received to
inform a
locally initiated transport connection.

Timeout An application-defined timer has expired while
waiting for some event.

Rcv-CER A CER message from the peer that was received.

Rcv-CEA A CEA message from the request could not be satisfied at peer was received.

Peer-Disc A disconnection indication from the time it peer was received, but MAY be able to satisfy
received.

Win-Election An election was held, and the request if local node was the error
winner.

Send-Message A Non-DRI message is
corrected.

DIAMETER_UNSUPPORTED_TRANSFORM 4001 to be sent.

Rcv-Non-DRI A Non-DRI message was received that included an CMS-Data AVP [11] that
made use of an unsupported transform.

9.2.2.4 Permanent Failure Events

Errors received.

WatchDog-Timer The Watchdog timer expired, indicating that fall within the permanent failures category are used a DWR
message is to be sent to
inform the peer peer.

Rcv-DWA A DWA message was received.

Stop The Diameter application has signaled that the request failed, and cannot a
connection should be satisfied terminated (e.g., on system
shutdown).

8.3 Actions

Actions in the automaton are caused by events and typically indicate
the originator transmission of packets and/or an action to be taken on the Device-Status-Ind. The receiver
connection. In this section we will ignore the -I and -R prefix,
since the actual action would be identical, but would occur on one of a DSI
message
two possible connections.

Snd-Conn-Req A transport connection is initiated with the DSI-Event set peer.

Snd-Conn-Ack an acknowledgement is sent in response to a value connect
request, confirming that falls within this
event class SHOULD forward the transport layer
connection is open.

Snd-CER A CER message to an alternate peer, if one is available.

DIAMETER_INVALID_ROUTE_RECORD 5001
The last Route-Record AVP in sent to the peer.

Calhoun et al. expires December 2001 [Page 54]

Internet-Draft June 2001

Snd-CEA A CEA message is not set sent to the
identity of the sender of peer.

Cleanup If necessary, the message. See connection is shutdown, and any
local resources are freed.

Error The transport layer connection is disconnected,
either politely or abortively, in response to an
error condition. Local resources are freed.

Process-CER A received CER is processed.

Process-CEA A received CEA is processed.

Disc The transport layer connection is disconnected, and
local resources are freed.

Elect An election occurs (see Section 11.0 8.4 for more information.

DIAMETER_COMMAND_UNSUPPORTED 5002
information).

Snd-Non-DRI A non-DRI message is sent.

Snd-DWR A DWR message is sent.

Process-DWA The Request contained a Command-Code that the receiver did not
recognize or support.

DIAMETER_UNABLE_TO_DELIVER 5003 DWA message is serviced.

Process A non-DRI Diameter message is serviced.

8.4 The request could not be delivered to a host that handles the
realm, and extension, requested at this time.

DIAMETER_REALM_NOT_SERVED 5004 Election Process

The originator of election is performed on the DSI message could not deliver responder. The responder compares
the message
since Origin-Host received in the realm requested is unknown.

DIAMETER_TOO_BUSY 5005
When returned, a Diameter node SHOULD attempt to DRI sent by its peer with its own
Origin-Host (which it may or may not have actually sent). The
transport layer connection with the
message to an alternate peer. This higher value MAY also be used to
inform a peer of Origin-Host is
the one that survives. The comparison proceeds by considering the request is not expected
shorter OctetString to be processed
within null-padded to the Max-Wait-Time value, length of the longer,
then performing an octet by octet unsigned comparison with the first
octet being most significant. Hanging octets are assumed to have
value 0x80, but dimpled octets are ignored.

9.0 Error Handling

There are two different types of errors in Diameter; protocol and
applications. A protocol error is giving up one that occurs at the base
protocol level, and MAY require per hop attention (e.g. message
routing error). Application errors, on the
request.

DIAMETER_CANNOT_PROCESS_IN_TIME 5006
The time limit other hand, are generally
occur due to a problem with a function specified in a request's Max-Wait-Time AVP has expired,
and no response is available.

DIAMETER_NO_COMMON_EXTENSION 5007 Diameter

Calhoun et al. expires October December 2001 [Page 46] 55]

Internet-Draft May June 2001

This event

application (e.g. user authentication, Missing AVP).

Result-Code AVP values that are used to report protocol errors MUST
be used in the Message-Reject-Answer command. Unlike most Diameter
commands, the Message-Reject-Answer does not have a corresponding
request.

When a request message is returned when received that causes a DRI protocol error, the
command code is changed to Message-Reject-Answer, and the Result-Code
AVP is set to the appropriate protocol error value. As the answer is
sent back towards the originator of the request, each proxy or relay
agent MAY take action on the message.

1. Request +---------+ Link Broken
+-------------------------->|Diameter |----///----+
| +---------------------| | v
+------+--+ | 2. MRA | Relay 2 | +--------+
|Diameter |<-+ (Unable to Forward) +---------+ |Diameter|
| | | Home |
| Relay 1 |--+ +---------+ | Server |
+---------+ | 3. Request |Diameter | +--------+
+-------------------->| | ^
| Relay 3 |-----------+
+---------+
Figure 4 - Example of Protocol Error causing MRA message is received, and
there are no common extensions supported between the peer.

DIAMETER_UNSUPPORTED_VERSION 5008
This event is returned when

Figure 4 provides an example of a DRI message is received, and the forwarded upstream by a
Diameter relay. When the message is unsupported.

9.3 Failed-AVP AVP

The Failed-AVP AVP (AVP Code 279) is of type Grouped received by Relay 2, and provides
debugging information in cases where a it
detects that it cannot forward the request is rejected or not
fully processed due to erroneous information in a specific AVP. The
value of the Result-Code AVP will provide information on the reason
for the Failed-AVP AVP.

Failed-AVP = Offending-AVP Failed-Vendor-Id
Offending-AVP = ; See Section 9.4
Failed-Vendor-Id = ; See Section 9.5

A Diameter home server, an MRA
message MAY contain one or more Failed-AVP AVPs, each
containing a complete is returned with the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER. Given that could not be processed successfully.
The possible reasons for this AVP are the presence of an improperly
constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
value, the omission of a required AVP, error falls within the presence of an explicitly
excluded AVP (see table 13.0), or
protocol error category, Relay 1 would take special action, and given
the presence of two or more
occurrences of an AVP which table 15.1 restricts error, attempt to 0, 1, or 0-1
occurrences.

+---------------------------------------------------------------+ route the message through its alternate Relay
3.

+---------+ 1. Request +---------+ 2. Request +---------+
| AVP Header (AVP Code = 279) Access |------------>|Diameter |------------>|Diameter |
+---------------------------------------------------------------+
| Offending-AVP AVP |
+---------------------------------------------------------------+ | Failed-Vendor-Id AVP |
+---------------------------------------------------------------+

9.4 Offending-AVP AVP

The Offending-AVP AVP (AVP Code 271) is | Home |
| Device |<------------| Relay |<------------| Server |
+---------+ 4. Answer +---------+ 3. Answer +---------+
(Missing AVP) (Missing AVP)
Figure 5 - Example of Application Error Answer message

Figure 5 provides an example of type OctetString and
contains a Diameter message that caused an
application error. When application errors occur, the offending AVP.

9.5 Failed-Vendor-Id AVP

The Failed-Vendor-Id AVP (AVP Code 262) is of type Unsigned32 and
contains Diameter entity
reporting the Vendor-Id of error clears the 'R' bit in the Command Flags, and adds
the Result-Code AVP that caused with the proper value. Application errors do not
require any proxy or relay agent involvement, and therefore the error.

Calhoun et al. expires October December 2001 [Page 47] 56]

Internet-Draft May June 2001

10.0 "User" Sessions

Diameter can provide two different type of services

message would be forwarded back to applications.
The first involves authentication and authorization, and can
optionally make use of accounting. The second only makes use of
accounting.

When a service makes use of the authentication and/or authorization
portion originator of an extension, and a user requests access to the network, the Diameter client issues an auth request request.

There are certain Result-Code AVP application errors that require
additional AVPs to its local server. The
auth request is defined in a service specific Diameter extension
(e.g. NASREQ). The request contains a Session-Id AVP, which is used be present in subsequent messages (e.g. subsequent authorization, accounting,
etc) relating to the user's session. The Session-Id answer, such as:

- An unrecognized AVP is a means
for received with the client and servers 'M' bit (Mandatory bit)
set, causes an answer to correlate a Diameter message be sent with a
user session.

When a Diameter server authorizes a user to use network resources, it
SHOULD add the Authorization-Lifetime Result-Code AVP set to
DIAMETER_AVP_UNSUPPORTED, and the response. The
Authorization-Lifetime Failed-AVP AVP defines the maximum amount of time a user
MAY make use of containing the resources before another authorization request
offending AVP.
- An AVP that is received with an unrecognized value causes an
answer to be transmitted to the server. If the server does not receive
another authorization request before returned with the timeout occurs, it SHOULD
release any state information related Result-Code AVP set to
DIAMETER_INVALID_AVP_VALUE, with the user's session. Note
that Failed-AVP AVP containing
the Authorization-Lifetime AVP implies how long causing the Diameter
server error.
- A command is willing received with an AVP that is ommitted, yet is
mandatory according to pay for the services rendered, therefore a
Diameter client SHOULD NOT expect payment for services rendered past the session expiration time. command's ABNF. The base protocol does not include any authorization request
messages, since these are largely application-specific and are
defined in a Diameter protocol extension document. However, receiver issues
an answer with the base
protocol does define a Result-Code set of messages that are used to terminate
user sessions. These are used to allow servers that maintain state
information to free resources.

When a service only makes use of the Accounting portion of the
Diameter protocol, even in combination with DIAMETER_MISSING_AVP, and
creates an extension, AVP with the
Session-Id AVP Code and other fields set to the
missing AVP's. The created AVP is still used then added to identify user sessions. However, the
session termination Failed-AVP
AVP.

The Result-Code AVP contains additional errors conditions, and
defines the expected behavior of each.

9.1 Result-Code AVP

The Result-Code AVP (AVP Code 268) is of type Unsigned32 and
indicates whether a particular request was completed successfully or
whether an error occurred. All Diameter answer messages are not used, since MUST include
one Result-Code AVP. A non-successful Result-Code AVP (one containing
a session non 2xxx value) MUST include the Error-Reporting-Host AVP if the
host setting the Result-Code AVP is
signaled as being terminated by issuing an accounting stop message.

10.1 Authorization Session State Machine

This section different from the identity
encoded in the Origin-Host AVP.

The Result-Code data field contains a finite state machine, an IANA-managed 32-bit address
space representing errors (see section 15.4). Diameter provides the life
cycle
following classes of Diameter sessions, and MUST be observed by errors, all Diameter
implementations that makes use of identified by the authentication and/or

Calhoun et al. expires October 2001 [Page 48]

Internet-Draft May 2001

authorization portion of a Diameter extension. The term Service-
Specific below refers to a message thousands digit:
- 1xxx (Informational)
- 2xxx (Success)
- 3xxx (Protocol Errors)
- 4xxx (Transient Failures)
- 5xxx (Permanent Failure)

A non-recognize class (one whose first digit is not defined in this
section) MUST be handled as a Diameter extension
(e.g. Mobile IP, NASREQ).

The following table contains the authorization session state machine.

State Event Action New State
-------------------------------------------------------------
Idle Client or Device Requests send Pending
access service
specific
auth req

Idle Service-Specific authorization send serv. Open
request received, and specific
successfully processed response

Pending Successful Service-Specific Grant Open
Authorization response Access
received

Open Authorization-Lifetime about send Open
to expire on access device service
specific
auth req

Open Successful Service-Specific Extend Open
Authorization response Access
received

Open Accounting message sent or process Open
received

Open Failed Service-Specific Discon. Closed
Authorization response user/device
received.

Open Session-Timeout Expires on send STR Discon
Access Device

Open STI Received send STR Discon

Open Session-Timeout or send STI Discon
Authorization-Lifetime
expires on home AAA server

Discon STI Received ignore Discon permanent failure.

9.1.1 Informational

Calhoun et al. expires October December 2001 [Page 49] 57]

Internet-Draft May June 2001

Discon STR Received Send STA Closed

Discon STA Received Discon. Closed
user/device

Closed Transition

Errors that fall within this category are used to state Cleanup

When inform the Cleanup
requester that a request could not be satisfied, and additional
action is invoked, the required on its part before access is granted.

DIAMETER_MULTI_ROUND_AUTH 1001
This informational error is returned by a Diameter node MAY attempt server to
release all resources for
inform the particular session. Any event not
listed above MUST be considered as an error condition, access device that the authentication mechanism
being used required multiple round trip, and a
response, if applicable, MUST subsequent
request needs to be returned issued in order for access to the originator of the
message.

10.2 Accounting Session State Machine

For applications be granted.

9.1.2 Success

Errors that only require accounting services, fall within the following
state machine MUST be supported.

State Event Action New State
-------------------------------------------------------------
Idle Client or device requests send Pending
access accounting
start req.

Idle Accounting start request send Open
received, and successfully accounting
processed. start
answer

Pending Successful accounting grant Open
start answer received access

Open Receive Interim Record send Open
accounting
answer

Open User service terminated send Discon
accounting
stop req.

Open Accounting stop Success category are used to inform a
peer that a request send Closed
received, and has been successfully accounting
processed stop answer

Discon Successful accounting discon. Closed
stop answer received user/device

Calhoun et al. expires October 2001 [Page 50]

Internet-Draft May completed.

DIAMETER_SUCCESS 2001

10.3 Session-Id AVP
The Session-Id AVP (AVP Code 263) is of type OctetString Request was successfully completed.

9.1.3 Protocol Errors

Errors that fall within the Protocol Error category SHOULD be treated
on a per-hop basis, and Diameter proxies MAY attempt to correct the
error, if it is possible. Note that these errors MUST only be used
to identify in
the Message-Rejected-Answer message, therefore a specific session (see section 10.0). Diameter entity that
wishes to return an error in this category MUST change the command
code to Message-Rejected-Answer message.

DIAMETER_INVALID_ROUTE_RECORD 3001
The Session-Id
data uses last Route-Record AVP in the UTF-8 [24] character set. All messages pertaining message is not set to the
identity of the sender of the message. See Section 11.0 for
more information.

DIAMETER_COMMAND_UNSUPPORTED 3002
The Request contained a
specific session MUST include only one Session-Id AVP and Command-Code that the same
value MUST receiver did not
recognize or support.

DIAMETER_UNABLE_TO_DELIVER 3003
The request could not be used throughout delivered to a host that handles the life
realm, and application, requested at this time.

DIAMETER_REALM_NOT_SERVED 3004
The intended realm of a session. When present, the Session-Id offending message is unknown.

DIAMETER_TOO_BUSY 3005
When returned, a Diameter node SHOULD appear immediately following attempt to sent the Diameter
Header (see section 3.0).

For messages that do not pertain
message to an alternate peer.

Calhoun et al. expires December 2001 [Page 58]

Internet-Draft June 2001

DIAMETER_INVALID_CMS_DATA 3006
The Request did not contain a specific session, multiple
Session-Id AVPs valid CMS-Data [11] AVP.

DIAMETER_LOOP_DETECTED 3007
An agent detected a loop while trying to get the message to the
Home Diameter server. The message MAY be present as long as they are encapsulated
within sent to an AVP alternate
peer, if one is available, but the peer reporting the error has
identified a configuration problem.

DIAMETER_END_2_END_SECURITY 3008
A proxy has detected that end-to-end security has been applied
to portions of type Grouped.

The Session-Id MUST be globally unique at any given time the Diameter message, and the proxy does not
allow this security mode since it is
used needs to alter the message by
applying some local policies.

9.1.4 Transient Failures

Errors that fall within the server transient failures category are used to identify the session (or flow). The format of
inform a peer that the session identifier SHOULD request could not be as follows:

<Sender's Origin-FQDN><sender's port number> <monotonically
increasing 32 bit value><optional value>

The monotonically increasing 32 bit value SHOULD NOT start at zero
upon reboot, but rather start satisfied at a random value. This will minimize the possibility of overlapping Session-Ids after a reboot.
Alternatively, an implementation time it
was received, but MAY keep track of be able to satisfy the increasing
value request in non-volatile memory. The optional value is implementation
specific but may include a modem's device Id, a layer 2 address,
timestamp, etc.

The session Id is created by the Diameter device initiating future.

DIAMETER_AUTHENTICATION_REJECTED 4001
The authentication process for the
session, which in user failed, most cases is done likely due
to an invalid password used by the client. Note that a
Session-Id MAY user. Further attempts MUST
only be used by more than one extension (e.g.
authentication tried after prompting the user for a specific service and accounting, both of which
have separate extensions).

10.4 Authorization-Lifetime AVP

The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
and contains new password.

DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the maximum number of seconds of service accounting request but was unable
to be provided commit it to stable storage due to a temporary lack of
space.

9.1.5 Permanent Failures

Errors that fall within the permanent failures category are used to
inform the user before peer that the user is to be re-authenticated and/or re-
authorized. Great care request failed, and should not be taken when the Authorization-
Lifetime value attempted
again.

DIAMETER_USER_UNKNOWN 5001
A request was received for a user that is determined, since unknown, therefore
authentication and/or authorization failed.

DIAMETER_AVP_UNSUPPORTED 5002
The peer received a low value could create
significant Diameter traffic, which could congest both the network
and the servers.

If both this message that contained an AVP that is not
recognized or supported and was marked with the Session-Timeout Mandatory bit.
A Diameter message with this error MUST contain one or more
Failed-AVP AVP are present in a
message, the value of containing the latter MUST NOT be smaller than AVPs that caused the failure.

Calhoun et al. expires October December 2001 [Page 51] 59]

Internet-Draft May June 2001

Authorization-Lifetime AVP.

This AVP MAY be provided by

DIAMETER_UNKNOWN_SESSION_ID 5003
The request contained an unknown Session-Id.

DIAMETER_AUTHORIZATION_REJECTED 5004
A request was received for which the client as a hint of user could not be
authorized. This error could occur if the maximum
duration that it service requested is willing
not permitted to accept. However, the server DOES NOT
have to observe user.

DIAMETER_INVALID_AVP_VALUE 5005
The request contained an AVP with an invalid value in its data
portion. A Diameter message indicating this error MUST include
the hint, and MAY return offending AVPs within a value Failed-AVP AVP.

DIAMETER_MISSING_AVP 5006
The request did not contain an AVP that is smaller than required by the hint. A value of zero means that no re-authorization is required.

10.5 Session-Timeout AVP

The Session-Timeout AVP (AVP
Command Code 27) [1] definition. If this value is of type Unsigned32 and
contains sent in the maximum number of seconds of service to Result-
Code AVP, a Failed-AVP AVP SHOULD be provided to included in the user before termination message.
The data portion of the session. A session terminated due
to the Session-Timeout expiration Failed-AVP MUST NOT generate a re-
authentication and/or re-authorization. contain an AVP header
containing the AVP Code and vendor-Id.

DIAMETER_AUTHORIZATION_FAILED 5007
A value of zero, or request was received for which the absence of this AVP, means that user could not be
authorized at this session
has an unlimited number of seconds before termination. time. This AVP MAY be provided by error could occur when the client as user
has already expended allowed resources, or is only permitted to
access services within a hint of time period.

DIAMETER_CONTRADICTING_AVPS 5008
The Home Diameter server has detected AVPs in the maximum
duration request that it
contradicted each other, and is not willing to accept. However, the server DOES NOT
have provide service
to observe the hint, and MAY return a value that is smaller than user. One or more Failed-AVP AVPs MUST be present,
containing the hint.

10.6 User-Name AVPs that contradicted each other.

DIAMETER_AVP_NOT_ALLOWED 5009
A message was received with an AVP that MUST NOT be present.
The User-Name Failed-AVP AVP MUST be included and contain the AVP (AVP Code 1) [1] is of type OctetString, which
contains
the User-Name. The value is represented as a UTF-8
character encoded string offending AVP.

DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010
A message was received that included an AVP that appeared more
often than permitted in a format consistent with the NAI
specification [8].

10.7 Max-Wait-Time AVP

The Max-Wait-Time AVP (AVP Code 295) is of type Unsigned32, message definition. The Failed-AVP
AVP MUST be included and
contains contain the maximum number AVP Code of milliseconds the downstream server is
willing to wait for a response. A offending
AVP.

DIAMETER_VENDOR_ID_UNSUPPORTED 5011
The Home Diameter server that determines that it
cannot satisfy a request within has detected vendor-specific AVPs in
the requested time MUST issue a DSI
message with message, and the DSI-Event set to DIAMETER_STILL_WORKING vendor dictionary is not supported. One or
DIAMETER_CANNOT_PROCESS_IN_TIME.

10.8 Session Termination

The Diameter Base Protocol provides a set of messages that
more Failed-AVP MUST be
used by any peer to explicitly request that a previously
authenticated and/or authorized session be terminated. Since present, containing the offending AVPs.

Calhoun et al. expires October December 2001 [Page 52] 60]

Internet-Draft May June 2001

Session-Id

DIAMETER_UNSUPPORTED_TRANSFORM 5012
A message was received that included an CMS-Data AVP [11] that
made use of an unsupported transform.

DIAMETER_NO_COMMON_APPLICATION 5013
This error is typically tied to returned when a particular service (i.e. Mobile IP,
NASREQ, etc), the session termination messages CEA message is received, and
there are used to request
that the service tied to no common applications supported between the Session Id be terminated.

Session Termination MAY be initiated by a Diameter server, by issuing peer.

DIAMETER_UNSUPPORTED_VERSION 5014
This error is returned when a Session-Termination-Ind (STI) CEA message to is received, and the access device. An
access device MUST issue a Session-Termination-Request (STR)
Diameter message
either upon receipt of an STI, or when service to a particular user is terminated.

A Diameter server MUST clean up resources (e.g. session state) if a
session's authorization lifetime has expired, and no STR was
received. unsupported.

DIAMETER_UNABLE_TO_COMPLY 5015
This event could occur if an access device was to
unexpectedly reboot.

An access device MUST issue Session-Termination-Request messages for
all active session prior to an orderly reboot.

10.8.1 Session-Termination-Ind error is returned when a request is rejected for
unspecified reasons.

9.2 Message-Reject-Answer

The Session-Termination-Ind (STI), Message-Reject-Answer (MRA), indicated by the Command-Code set to 274
282, and the message flags' 'I' Command Flags' 'R' bit set, MAY be cleared, is sent by any
Diameter entity to the access device in response to a
request that has caused a particular
session be terminated. This message MAY be protocol error.

Although the command code is different from the one found in the
request, the same procedures used when a server detects
that a session MUST be terminated, which in issuing an answer message is typically done as a
policy decision (e.g. local resources have been expended, etc).
followed. The
Destination-FQDN Result-Code AVP MUST be present, and contain include a value in
the fully qualified
domain name of "Protocol Error" category.

Proxies receiving an MRA message MAY attempt to rectify the access device error
reported, if possible. In the event that initiated no proxy is able to correct
the session (see
section 10.0).

A Failed STI would contain problem, the same Command-Code, but would require
that only be 'F' bit MRA will be set.

Upon receipt of returned to the STI message, originator of the access device MUST issue a
Session-Terminate-Request
request message.

Message Format

Calhoun et al. expires October 2001 [Page 53]

Internet-Draft May 2001

<Session-Termination-Ind>

<Message-Reject-Answer> ::= < Diameter Header: 274, I 282 >
< Session-Id >
{ Origin-FQDN Origin-Host }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm Result-Code }
{ Destination-FQDN Destination-Host }
* [ AVP ]
*
[ Proxy-Info Origin-State-Id ]
* [ Route-Record AVP ]

10.8.2 Session-Termination-Request

9.3 Error-Message AVP

The Session-Termination-Request (STR), indicated Error-Message AVP (AVP Code 281) is of type OctetString. It is a

Calhoun et al. expires December 2001 [Page 61]

Internet-Draft June 2001

human readable UTF-8 character encoded string. It MAY accompany a
Result-Code AVP as a human readable error message. The Error-Message
AVP is not intended to be useful in real-time, and SHOULD NOT be
expected to be parsed by network entities.

9.4 Error-Reporting-Host AVP

The Error-Reporting-Host AVP (AVP Code 294) is of type OctetString,
encoded in the Command-Code
set UTF-8 [24] format, according to 275 and the message flags' 'R' bit set, is sent by Diameter identity
rules defined in section 2.7. This AVP contains the access
device to inform identity of the
Diameter Server host that an authenticated and/or
authorized session is being terminated.

If set the STR message Result-Code AVP to a value other than 2001
(Success), only if the host setting the Result-Code is generated upon receipt of an STI, different from
the Route-
Record AVPs one encoded in the STI Origin-Host AVP. This AVP is intended to be
used for troubleshooting purposes, and MUST NOT be added to set when the STR.

Message Format

<Session-Termination-Request> ::= < Diameter Header: 275, R >
< Session-Id >
{ Origin-FQDN }
{ Origin-Realm }
{ User-Name }
{ Destination-Realm }
{ Destination-FQDN }
[ Max-Wait-Time ]
* [ Result-
Code AVP indicates a failure.

9.5 Failed-AVP AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

10.8.3 Session-Termination-Answer

The Session-Termination-Answer (STA), indicated by the Command-Code
set to 275 Failed-AVP AVP (AVP Code 279) is of type Grouped and the message flags' 'A' bit set, provides
debugging information in cases where a request is sent by the
Diameter Server rejected or not
fully processed due to acknowledge that the session has been terminated. erroneous information in a specific AVP. The
value of the Result-Code AVP MUST be present, and will provide information on the reason
for the Failed-AVP AVP.

The possible reasons for this AVP are the presence of an improperly
constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
value, the omission of a required AVP, the presence of an explicitly
excluded AVP (see table 12.0), or the presence of two or more
occurrences of an AVP which table 14.1 restricts to 0, 1, or 0-1
occurrences.

A Diameter message MAY contain an indication one Failed-AVP AVP, containing the
entire AVP that an error occurred while servicing could not be processed successfully. If the STR.

Upon sending or receipt failure
reason is omission of a required AVP, an AVP with the STA, the Diameter Server MUST release
all resources for missing AVP
code, the session indicated by missing vendor id, and a zero filled payload of the Session-Id AVP. Any
intermediate server in minimum
required length for the Proxy-Chain MAY also release any ommitted AVP will be added.

AVP Format

<Failed-AVP> ::= < AVP Header: 279 >
1* {AVP}

10.0 "User" Sessions

Diameter can provide two different type of services to applications.

Calhoun et al. expires October December 2001 [Page 54] 62]

Internet-Draft May June 2001

resources, if necessary.

Message Format

<Session-Termination-Answer> ::= <

The first involves authentication and authorization, and can
optionally make use of accounting. The second only makes use of
accounting.

When a service makes use of the authentication and/or authorization
portion of an application, and a user requests access to the network,
the Diameter Header: 275, A >
< client issues an auth request to its local server. The
auth request is defined in a service specific Diameter application
(e.g. NASREQ). The request contains a Session-Id >
{ Result-Code }
{ Origin-FQDN }
{ Origin-Realm }
{ Destination-FQDN }
{ User-Name }
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

11.0 Message Routing

This section describes AVP, which is used
in subsequent messages (e.g. subsequent authorization, accounting,
etc) relating to the expected behavior of user's session. The Session-Id AVP is a Diameter server
acting as means
for the client and servers to correlate a proxy or redirect server.

11.1 Realm-Based Message Routing Diameter request and indication message routing is done via realms.
A with a
user session.

When a Diameter entity creating server authorizes a message that is proxyable MUST include user to use network resources, it
SHOULD add the realm in Authorization-Lifetime AVP to the Destination-Realm AVP. answer message. The realm MAY be retrieved
from the User-Name AVP, which is in
Authorization-Lifetime AVP defines the form maximum amount of time a Network Access
Identifier (NAI). The realm portion user
MAY make use of the NAI resources before another authorization request is inserted in
to be transmitted to the server. If the server does not receive
another authorization request before the timeout occurs, it SHOULD
release any state information related to the user's session. Note
that the Authorization-Lifetime AVP implies how long the
Destination-Realm AVP. Diameter servers have
server is willing to pay for the services rendered, therefore a list of locally supported realms,
Diameter client SHOULD NOT expect payment for services rendered past
the session expiration time.

The base protocol does not include any authorization request
messages, since these are largely application-specific and MAY
have are
defined in a list of externally supported realms. When Diameter application document. However, the base
protocol does define a request or
indication message is received set of messages that includes a realm are used to terminate
user sessions. These are used to allow servers that is not
locally supported, the message is proxied maintain state
information to free resources.

When a service only makes use of the Accounting portion of the
Diameter entity
configured protocol, even in the "route" table (see section 11.1.1).

Figure 2 depicts an example where NAS is combination with an access device and
receives a request for network access from jow@abc.com. NAS looks up
"abc.com" in its local realm route table and determines that the
message must be proxied to PRS (Proxy Server). PRS does the same
check, and proxies application, the message
Session-Id is still used to HMS (Home Server). HMS checks its
realm route table, and determines that identify user sessions. However, the realm
session termination messages are not used, since a session is locally
supported, and processes
signaled as being terminated by issuing an accounting stop message.

10.1 Authorization Session State Machine

This section contains a finite state machine, representing the authentication request, life
cycle of Diameter sessions, and returns the
response. How the response actually MUST be observed by all Diameter
implementations that makes it back to the sender use of the original request is described authentication and/or
authorization portion of a Diameter application. The term Service-
Specific below refers to a message defined in a Diameter application
(e.g. Mobile IP, NASREQ).

Calhoun et al. expires December 2001 [Page 63]

Internet-Draft June 2001

The following table contains the next section. authorization session state machine.

State Event Action New State
-------------------------------------------------------------
Idle Client or Device Requests send Pending
access service
specific
auth req

Idle Service-Specific authorization send serv. Open
request received, and specific
successfully processed answer

Pending Successful Service-Specific Grant Open
Authorization answer Access
received

Pending Successful Service-Specific Sent STR Discon
authorization answer received
but service not provided

Pending Error processing successful Sent STR Discon
Service-Specific authorization
answer

Open Authorization-Lifetime about send Open
to expire on access device service
specific
auth req

Open Successful Service-Specific Extend Open
Authorization answer Access
received

Open Accounting message sent or process Open
received

Open Failed Service-Specific Discon. Closed
Authorization answer user/device
received.

Open Session-Timeout Expires on send STR Discon
Access Device

Open SKR Received send SKA, Discon
STR

Open Session-Timeout or Cleanup Discon

Calhoun et al. expires October December 2001 [Page 55] 64]

Internet-Draft May June 2001

(Origin-FQDN=nas.mno.net) (Origin-FQDN=nas.mno.net)
(Origin-Realm=mno.net) (Origin-Realm=mno.net)
(Destination-Realm=abc.com) (Destination-Realm=abc.com)
(Route-Record=prs.mno.net)
+------+ ------> +------+ ------> +------+
| | (Request) | | (Request) | |
| NAS +-------------------+ PRS +-------------------+ HMS |
| | | | | |
+------+ <------ +------+ <------ +------+
mno.net (Answer) mno.net (Answer) abc.com
(Origin-FQDN=hms.abc.com) (Origin-FQDN=hms.abc.com)
(Origin-Realm=abc.com) (Origin-Realm=abc.com)
(Destination-FQDN=nas.mno.net) (Destination-FQDN=nas.mno.net)
(Route-Record=prs.mno.net)
Figure 2: Realm-Based Routing
The above example can also be used for Indication and Failed-
Indication messages.

Note the processing rules contained in this section are intended to
be used as general guidelines to Diameter developers. Certain
implementations MAY use different methods than the ones described
here, and still be in compliance with the protocol specification.

11.1.1 Realm-Based Routing Table

All Realm-Based routing lookups are performed against what is
commonly known as the Domain Routing Table (see section 18.0). A
Domain Routing Table Entry contains the following fields:
- Domain Name. The Domain Name is analogous to the realm portion
of the NAI. This is the field that is typically used as a
primary key in the routing table lookups. Note that some
implementations perform their lookups based on longest-match-
from-the-right

Authorization-Lifetime
expires on the realm rather than requiring an exact
match.
- Extension Identifier. It is possible for a routing entry home AAA server

Open SKA Received Cleanup Closed

Discon SKR Received ignore Discon

Discon STR Received Send STA Closed

Discon STA Received Discon. Closed
user/device

Closed Transition to have
a different destination based on the Auth-Extension-Id (for
accounting messages) or Acct-Extension-Id (for non-accounting
messages) of state Cleanup

When the message. This field is typically used as a
secondary key field in routing table lookups.
- Local Action. The Local Action field Cleanup action is used to identify how a
message should be treated. The following actions are supported:
1. LOCAL - invoked, the Diameter messages that resolve node MAY attempt to a routing entry
with
release all resources for the Local Action set to Local can particular session. Any event not
listed above MUST be satisfied
locally, considered as an error condition, and do not need to an answer,
if applicable, MUST be forwarded returned to another
server.
2. PROXY - All Diameter messages the originator of the message.

10.2 Accounting Session State Machine

For applications that fall within this
category only require accounting services, the following
state machine MUST be forwarded to a next hop server. The local supported.

Calhoun et al. expires October December 2001 [Page 56] 65]

Internet-Draft May June 2001

server MAY apply its local policies to the message by
including new AVPs to the message prior to forwarding.
See section 11.4 for more information.
3. REDIRECT - Diameter messages that fall within this
category MUST have the identity

State Event Action New State
-------------------------------------------------------------
Idle Client or device requests send Pending
access accounting
start req.

Idle Accounting start request send Open
received, and successfully accounting
processed. start
answer

Pending Successful accounting grant Open
start answer received access

Open Receive Interim Record send Open
accounting
answer

Open User service terminated send Discon
accounting
stop req.

Open Accounting stop request send Closed
received, and successfully accounting
processed stop answer

Discon Successful accounting discon. Closed
stop answer received user/device

10.3 Session-Id AVP

The Session-Id AVP (AVP Code 263) is of the home Diameter
server(s) appended, type OctetString and returned is used
to the sender of the
message. See identify a specific session (see section 11.3 for more information.
- Server Identifier - One or more servers 10.0). The Session-Id
data uses the message is UTF-8 [24] character set. All messages pertaining to be
forwarded to. When a
specific session MUST include only one Session-Id AVP and the Local Action is set to PROXY, this field
contains same
value MUST be used throughout the identities life of the server(s) the message must be
forwarded to. a session. When present,
the Local Action field is set to REDIRECT,
this field contains Session-Id SHOULD appear immediately following the Home Diameter server(s) for the realm.

It is important to note
Header (see section 3.0).

For messages that Diameter servers MUST support at least
one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do not need pertain to support all modes a specific session, multiple
Session-Id AVPs MAY be present as long as they are encapsulated
within an AVP of operation in order to conform with
the protocol specification. Servers type Grouped.

The Session-Id MUST NOT reorder AVPs be globally and eternally unique, as it is meant
to uniquely identify a user session without reference to any other
information, and may be needed to correlate historical authentication
information with the
same AVP Code.

When accounting information. The Session-Id includes a

Calhoun et al. expires December 2001 [Page 66]

Internet-Draft June 2001

mandatory portion and an implementation-defined portion; a message is being proxied,
recommended format for the servers in a given domain
routing entry implementation-defined portion is outlined
below.

The Session-Id MUST have advertised begin with the Extension Identifier sender's identity (see section 6.1) for the given message, or have advertised the Wildcard
Extension.

11.2 Proxy and Redirect Server handling of requests

When a message
2.7). The remainder of type request or indication is received by a proxy
or redirect server, and it is determined that the request cannot Session-Id MAY be
locally handled, the next hop for any sequence that the request is determined in
client can guarantee to be eternally unique; however, the following order:
1. If the Destination-FQDN AVP
format is present, recommended, (square brackets [] indicate an optional
element):

<client FQDN>[:<port>];<high 32 bits>;<low 32 bits>[;<optional
value>]

<high 32 bits> and <low 32 bits> are decimal representations of the host specified
high and low 32 bits of a monotonically increasing 64-bit value. The
64-bit value is rendered in two part to simplify formatting by 32-bit
processors. At startup, the AVP can be directly contacted, high 32 bits of the message is forwarded 64-bit value MAY be
initialized to the host (see section 5.1 time, and the low 32 bits MAY be initialized to 0.
This will for more information), or
2. If practical purposes eliminate the Destination-Realm AVP is present, possibility of
overlapping Session-Ids after a routing table lookup
is performed using the domain specific in reboot, assuming the AVP.

A message that does not contain any reboot process
takes longer than a second. Alternatively, an implementation MAY keep
track of the above AVPs MUST NOT be
routed. If the message increasing value in question cannot be handled locally, an
answer or failed indication is sent with the Result-Code AVP set to
an appropriate error condition.

11.3 Redirect Server

A Redirect Server non-volatile memory.

<optional value> is one that provides Realm to Diameter Home Server
address resolution. When implementation specific but may include a message is received by modem's
device Id, a peer, the
Destination-Realm AVP (or the User-Name AVP if layer 2 address, timestamp, etc.

Example, in which the Destination-Realm

Calhoun et al. expires October 2001 [Page 57]

Internet-Draft May 2001

AVP is not present) standard port is extracted from the message, used and there is used to
perform a lookup no optional
value:

accesspoint7.acme.com;1876543210;523

Example, in which a non-standard port is used and there is an
optional value:

accesspoint7.acme.com:831;1876543210;523;mobile@200.1.1.88

The session Id is created by the domain routing table. Implementations MAY
also use Diameter device initiating the Extension Identifiers as a secondary key
session, which in most cases is done by the domain
routing table lookup.

Successful routing table lookups will return one or more home
Diameter servers client. Note that could satisfy a
Session-Id MAY be used for both the message. authorization and accounting
commands of a given application.

10.4 Authorization-Lifetime AVP

The home servers are
encoded in one or more Redirect-Host AVPs, Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
and contains the Command-Code field
is set maximum number of seconds of service to be provided
to Device-Status-Ind. The Hop-by-Hop field in the Diameter
header user before the user is set to be re-authenticated and/or re-
authorized. Great care should be taken when the Authorization-

Calhoun et al. expires December 2001 [Page 67]

Internet-Draft June 2001

Lifetime value found in the message causing the redirect.

+------------------+
| Diameter |
| Redirect Server |
+------------------+
^ |
Request | | DSI +
joe@xyz.com | | DSI-Event = Redirect +
| | Redirect-Host AVP(s)
| v
+----------+ Request +----------+
| abc.net |------------->| xyz.net |
| Diameter | | Diameter |
| Server |<-------------| Server |
+----------+ Answer +----------+
Figure 3: Diameter Redirect Server

Lastly, the DSI-Event AVP is added with determined, since a low value could create
significant Diameter traffic, which could congest both the Data field of network
and the agents.

If both this AVP set
to DIAMETER_REDIRECT_INDICATION, and the message is returned to the
sender of the request. Redirect servers MAY also include the
certificate of the Home server(s). These certificates Session-Timeout AVP are
encapsulated present in a CMS-Cert AVP [11]. When this occurs,
message, the server
forwarding value of the request directly to latter MUST NOT be smaller than the Home Diameter server SHOULD
include its own certificate in
Authorization-Lifetime AVP.

This AVP MAY be provided by the message.

The receiver client as a hint of the DSI message with the DSI-Event AVP set maximum
duration that it is willing to
DIAMETER_REDIRECT_INDICATION uses the hop-by-hop field in accept. However, the
Diameter header server DOES NOT
have to identify observe the message in hint, and MAY return a value that is smaller than
the pending message queue
(see Section 7.3) hint. A value of zero means that no re-authorization is to be redirected.

11.3.1 Redirect-Host required.

10.5 Session-Timeout AVP

The Redirect-Host Session-Timeout AVP (AVP Code 292) 27) [1] is of type Grouped Unsigned32 and is found
in Device-Status-Ind messages that include
contains the DSI-Event AVP set to
DIAMETER_REDIRECT_INDICATION. This AVP only needs maximum number of seconds of service to be used if provided to
the
host user before termination of the message is to be redirected session. A session terminated due
to is not listening on the
standard Diameter port. Its Data field has Session-Timeout expiration MUST NOT generate a re-
authentication and/or re-authorization.

A value of zero, or the following ABNF

Calhoun et al. expires October 2001 [Page 58]

Internet-Draft May 2001

grammar:

Redirect-Host = Redirect-Host-Address Redirect-Host-Port
Redirect-Host-Address = ; See Section 11.3.2
Redirect-Host-Port = ; See Section 11.3.3

The Redirect-Host-Address absence of this AVP, means that this session
has an unlimited number of seconds before termination.

This AVP Data field contains MAY be provided by the IP Address client as a hint of the Diameter host maximum
duration that it is willing to which the request MUST be redirected. The
Redirect-Host-Port contains accept. However, the port number server DOES NOT
have to which observe the request
should be sent. Upon receipt of such a event, hint, and this AVP, the
receiving host SHOULD send the request directly to the host
identified by MAY return a value that is smaller than
the Redirect-Host-Address AVP.

+---------------------------------------------------------------+
| AVP Header (AVP Code = 292) |
+---------------------------------------------------------------+
| Redirect-Host-Address AVP |
+---------------------------------------------------------------+
| Redirect-Host-Port AVP |
+---------------------------------------------------------------+

11.3.2 Redirect-Host-Address hint.

10.6 User-Name AVP

The Redirect-Host-Address User-Name AVP (AVP Code 278) 1) [1] is of type Address. Its
use is described in Section 11.3.1.

11.3.3 Redirect-Host-Port AVP OctetString, which
contains the User-Name. The Redirect-Host-Port AVP (AVP Code 277) is of type Unsigned32. Its
use value is described represented as a UTF-8
character encoded string in Section 11.3.1.

11.4 Proxy Server

This section outlines a format consistent with the processing rules NAI
specification [8].

10.7 Session Termination

It is necessary for a Diameter proxy
servers. A proxy server can either be stateful or stateless. A Proxy server MAY act in a stateful manner for some requests, and be
stateless for others. There are two types of states that servers MAY
wish to maintain; transaction and session.

Maintaining transaction state implies that authorized a server keeps a copy of a
request messages, which is then used when the corresponding response
is received. Maintaining transaction state also requires that the
Hop-by-Hop identifier MUST be saved, and restored session to its original
value be
notified when the corresponding response message that session is received. A Proxy
server MAY also add a Proxy-Info AVP no longer active, both for tracking
purposes as well as to allow stateful agents to request message, but MUST
remove release any resources
that they may have provided for the AVP in user's session.

When a user session that required Diameter authorization terminates,
the corresponding response. access device that provided the service MUST issue a Session-

Calhoun et al. expires October December 2001 [Page 59] 68]

Internet-Draft May June 2001

Maintaining session state implies that a

Termination- Request (STR) message to the Diameter server keeps track of all
"active" users. that
authorized the service, to notify it that the session is no longer
active. An active STR MUST be issued when a user is one session terminates for any
reason, including user logoff, expiration of Session-Timeout,
administrative action, termination upon receipt of an Abort-Session-
Request (see below), orderly shutdown of the access device, etc.

The access device also MUST issue an STR for a session that has been was
authorized but never actually started. This could occur, for example,
due to a
particular service, and sudden resource shortage in the server has access device, or because
the access device is unwilling to provide the type of service
requested in the authorization, or because the access device does not received any indication
support a mandatory AVP returned in the authorization, etc.

It is also possible that a session that was authorized is never
actually started due to action of a proxy. For example, a proxy may
modify an authorization answer, converting the user has relinquished access. result from success to
failure, prior to forwarding the message to the access device. A stateless
proxy is one that does not maintain causes an authorized session state, but
MUST maintain transaction state. Transaction state SHOULD not to be released
after a request's corresponding response has been forwarded towards started MUST issue
an STR to the recipient, and Diameter server that authorized the session, since the
access device has been acknowledged by no way of knowing that the underlying transport. session had been
authorized.

A stateful proxy is one Diameter server that maintains both transaction and receives an STR message MUST clean up
resources (e.g., session
state, state) associated with the latter being done by observing request Session-Id
specified in the STR, and responses.
Session state SHOULD be released once it is informed that return a user
and/or device has relinquished access. Session-Termination-Answer.

A stateful Diameter server MAY provide
the following features:
- Protocol translation (e.g. RADIUS <-> Diameter)
- Limiting also MUST clean up resources authorized to a particular user
- Per user when the Session-
Timeout expires, or transaction auditing

Home servers processing requests that include when the Route-Record and/or Authorization-Lifetime expires without
re-authorization, regardless of whether an STR for that session is
received. The access device is not expected to provide service beyond
the Proxy-Info AVPs MUST return expiration of these AVPs in timers; thus, expiration of either of these
timers implies that the same order in access device may have unexpectedly shut
down.

10.7.1 Session-Termination-Request

The Session-Termination-Request (STR), indicated by the
corresponding response.

11.4.1 Proxying Request and Indication messages

In addition Command-Code
set to 275 and the rules defined in section 11.2, the following
procedures MUST be handled Command Flags' 'R' bit set, is sent by the access
device to inform the Diameter Server that an authenticated and/or
authorized session is being terminated.

Message Format

Calhoun et al. expires December 2001 [Page 69]

Internet-Draft June 2001

<Session-Termination-Request> ::= < Diameter Header: 275, REQUEST
>
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ User-Name }
{ Termination-Cause }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

10.7.2 Session-Termination-Answer

The Session-Termination-Answer (STA), indicated by proxy servers handling messages of type
request or indication. Failed indications follow the proceduces in
section 11.4.2.

A proxy server MUST check for forwarding loops before proxying a
request or indication message. Such as message has been looped if Command- Code
set to 275 and the
server finds its own address in a Route-Record AVP.

A Diameter server that proxies a request or indication message MUST
append a Route-Record AVP, which includes its identity. flags' 'R' bit clear, is sent by the
Diameter
Servers Server to acknowledge the notification that receive messages MUST validate the last Route-Record session has
been terminated. The Result-Code AVP
in the message MUST be present, and ensure MAY contain
an indication that an error occurred while servicing the host identified in STR.

Upon sending or receipt of the AVP is STA, the
same as Diameter Server MUST release
all resources for the sender of session indicated by the message.

A Proxy Server Session-Id AVP. Any
intermediate server in the Proxy-Chain MAY also include the Proxy-Info release any
resources, if necessary.

Message Format

<Session-Termination-Answer> ::= < Diameter Header: 275 >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ User-Name }
[ Origin-State-Id ]
* [ AVP in ]
* [ Proxy-Info ]
* [ Route-Record ]

10.8 Aborting a request
message, which is used to encode local state information. The Proxy-
Info AVP is guaranteed to be present in the corresponding response.

The message is then forwarded to the downstream Session

A Diameter server, as
identified in server may request that the Domain Routing Table. access device stop providing
service for a particular session by issuing an Abort-Session-Request
(ASR).

Calhoun et al. expires October 2001 [Page 60]

Internet-Draft May 2001

Proxy Server MUST save the Hop-by-Hop Identifier in request messages,
if the value of expires December 2001 [Page 70]

Internet-Draft June 2001

For example, the field is changed, with a locally unique value.
The saved identifier MAY be encoded in Diameter server that originally authorized the Proxy-Info AVP, and will
session may be required in the processing of to cause that session to be stopped for
credit or other reasons that were not anticipated when the corresponding response.

11.4.2 Proxying Answer and Failed Ind messages

A proxy session
was first authorized. Or, an operator may maintain a management
server MUST only process messages of type Answer, or Ind
messages with for the 'F' bit, whose last Route-Record AVP matches one purpose of
its identities. Any responses that do not conform issuing ASRs to this rule MUST
be dropped. The last Route-Record AVP MUST be removed administratively remove
users from the
message before it is forwarded network.

An access device that receives an ASR with Session-ID equal to a
currently active session MAY stop the next hop, which is identified
by the second to last Route-Record AVP.

If session. Whether the last Proxy-Info AVP in access
device stops the message session or not is targeted to the local
Diameter server, implementation- and/or
configuration- dependent. For example, an access device may honor
ASRs from certain agents only. In any case, the AVP access device MUST be removed.

If a proxy server receives a response
respond with an Abort-Session-Answer, including a Result-Code AVP
indicating a failure, to
indicate what action it MUST NOT modify took.

Note that if the contents access device does stop the session upon receipt of
an ASR, it issues an STR to the AVP. Any
additional local errors detected SHOULD be logged, but authorizing server (which may or may
not reflected
in be the agent issuing the ASR) just as it would if the session
were terminated for any other reason.

10.8.1 Abort-Session-Request

The Abort-Session-Request (ASR), indicated by the Command-Code set to
274 and the Result-Code AVP.

Prior message flags' 'R' bit set, may be sent by any server to forwarding
the response, proxy servers MUST restore access device that is providing session service, to request that
the
original value of session identified by the Session-Id be stopped.

Message Format

<Abort-Session-Request> ::= < Diameter header's Hop-by-Hop Identifier field.

11.4.3 Route-Record Header: 274, REQUEST >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
[ Origin-State-Id ]
* [ AVP

The ]
* [ Proxy-Info ]
* [ Route-Record AVP (AVP Code 282) is of type OctetString, encoded
in the UTF-8 [24] format, and contains the Fully Qualified Domain
Name of the Proxy appending this AVP to a Diameter message. ]

10.8.2 Abort-Session-Answer

The FQDN
added in this AVP MUST be Abort-Session-Answer (ASA), indicated by the same as Command-Code set to
274 and the FQDN message flags' 'R' bit clear, is sent in response to the Origin-
FQDN in the Device-Reboot-Ind message.

11.4.4 Proxy-Info AVP

The Proxy-Info AVP (AVP Code = 284) is of type Grouped. The Grouped
Data field has the following ABNF grammar:

Proxy-Info = Proxy-Address Proxy-State
Proxy-Address = ; See Section 11.4.5
Proxy-State = ; See Section 11.4.6
ASR. The Proxy-Address Result-Code AVP Data field contains one of MUST be present, and indicates the IP addresses
disposition of the system that created the AVP. This assists hosts in determining
whether a Proxy-Info AVP is intended for the local host. The Proxy- request.

Calhoun et al. expires October December 2001 [Page 61] 71]

Internet-Draft May June 2001

State AVP contains state information, and MUST be treated as opaque
data.

+---------------------------------------------------------------+
| AVP Header (AVP Code = 284) |
+---------------------------------------------------------------+
| Proxy-Address AVP |
+---------------------------------------------------------------+
| Proxy-State AVP |
+---------------------------------------------------------------+

11.4.5 Proxy-Address AVP

The Proxy-Address AVP (AVP Code = 280)

If the session identified by Session-Id in the ASR was successfully
terminated, Result-Code is of type Address. Its use set to DIAMETER_SUCCESS. If the session is described in Section 11.4.4.

11.4.6 Proxy-State AVP

The Proxy-State AVP (AVP Code = 33)
not currently active, Result-Code is of type OctetString. Its use set to
DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the
session for any other reason, Result-Code is described in Section 11.4.4.

11.4.7 Destination-Realm set to
DIAMETER_UNABLE_TO_COMPLY.

Message Format

<Abort-Session-Answer> ::= < Diameter Header: 274 >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

10.9 Termination-Cause AVP

The Destination-Realm Termination-Cause AVP (AVP Code 283) 295) is of type OctetString,
encoded in the UTF-8 [24] format, Unsigned32, and contains
is used to indicate the realm reason why a session was terminated on the message
access device. The following values are defined:

DIAMETER_LOGOUT 1
The user initiated a disconnect

DIAMETER_SERVICE_NOT_PROVIDED 2
This value is used when the user disconnected prior to be routed to. The Destination-Realm AVP MUST NOT be present in
Answer or failed Indication messages. Diameter Clients insert the
realm portion
receipt of the User-Name AVP. Home servers initiating a request
or indication message use the authorization answer message.

DIAMETER_BAD_ANSWER 3
This value of indicates that the Origin-Realm AVP from a
previous message authorization answer received from the intended target host (unless it is
known a priori). When present, the Destination-Realm AVP is used to
perform message routing decisions.

11.5 Applying Local Policies

Proxies MAY apply local access policies to Diameter requests, or
responses, by adding, changing or deleting AVPs in
the messages.
Proxies that apply local policies MUST NOT allow end-to-end security
on any messages that traverse through it, unless security is
terminated locally.

A proxy wishing to modify a Diameter message to enforce some local
policy that detects that end-to-end security has been applied access device was not processed successfully.

DIAMETER_ADMINISTRATIVE 4
The user was not granted access, or was disconnected, due to
administrative reasons, such as the
message MUST return receipt of a response Session-Kill-
Request message.

DIAMETER_LINK_BROKEN 5
The communication to the originator with the Result-Code user was abruptly disconnected.

10.10 Inferring Session Termination from Origin-State-Id

Calhoun et al. expires October December 2001 [Page 62] 72]

Internet-Draft May June 2001

set

Origin-State-Id is used to DIAMETER_END_2_END_SECURITY. The originator allow rapid detection of terminated
sessions for which no STR would have been issued, due to
unanticipated shutdown of an access device.

By including Origin-State-Id in CER/CAA messages, an access device
allows a next-hop server to determine immediately upon connection
whether the request MAY
re-issue device has lost its sessions since the last connection.

By including Origin-State-Id in request messages, an access device
also allows a server with no end-to-end security if which it falls within
its local policy.

In communicates via proxy to make
such a determination. However, a server that is not directly
connected with the event access device will not discover that the Home Diameter server access
device has been restarted unless and until it receives a new request with
contradictory information (possibly due to some proxy adding
from the access device. Thus, use of this mechanism across proxies is
opportunistic rather than reliable, but useful nonetheless.

When a local
policy), Diameter server receives a Origin-State-Id that is greater
than the Origin-State-Id previously received from the same issuer, it MAY accept
may assume that the latest AVP, or MAY return issuer has lost state since the response
with previous message
and that all sessions that were active under the Result-Code AVP set lower Origin-State-
Id have been terminated. The Diameter server MAY clean up all session
state associated with such lost sessions, and MAY also issues STRs
for all such lost sessions that were authorized on downstream
servers, to DIAMETER_CONTRADICTING_AVPS. However,
an access device receiving allow session state to be cleaned up globally.

10.11 Origin-State-Id AVP

The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a response
monotonically increasing value that contains contradictory
information SHOULD reject service to the user.

11.6 Hiding Network Topology

Proxies forwarding requests to servers outside is advanced whenever a Diameter
entity restarts with loss of their
administrative domain previous state, for example upon reboot.
Origin-State-Id MAY hide the internal network topology. Servers
perform this by removing all Route-Record AVPs be included in the any Diameter message, and
maintains the Route-Record AVPs to add to the corresponding response.
Such servers including
CER.

A Diameter entity issuing this AVP MUST still add their own Route-Record create a higher value for
this AVP each time its state is reset. A Diameter entity MAY set
Origin-State-Id to the request
prior to forwarding.

11.7 Loop Detection

When a Diameter Proxy or Redirect server receives a request time of startup, or
indication message, it MUST examine all Route-Record AVPs MAY use an incrementing
counter retained in non-volatile memory across restarts.

The Origin-State-Id, if present, MUST reflect the
message to determine whether such an AVP already exists with state of the
local server's identity. entity
indicated by Origin-Host. If an AVP with the local host's identity is
found in the request, a proxy modifies Origin-Host, it MUST
either remove Origin-State-Id or modify it appropriately as well.

Typically, Origin-State-Id is used by an indication access device that the message is being
looped through the same set of proxies. When such an event occurs,
the Diameter server always
starts up with no active sessions; that detects the loop returns is, any session active prior
to restart will have been been lost. By including Origin-State-Id in
a response message, it allows other Diameter entities to infer that sessions
associated with the
Result-Code AVP a lower Origin-State-Id are no longer active. If an

Calhoun et al. expires December 2001 [Page 73]

Internet-Draft June 2001

access device does not intend for such inferences to be made, it MUST
either not include Origin-State-Id in any message, or set its value
to DIAMETER_LOOP_DETECTED.

12.0 0.

11.0 Accounting

This accounting protocol is based on a server directed model with
capabilities for real-time delivery of accounting information.
Several fault resilience methods [40] have been built in to the
protocol in order minimize loss of accounting data in various fault
situations and under different assumptions about the capabilities of
the used devices.

12.1

11.1 Server Directed Model

The server directed model means that the device generating the
accounting data gets information from either the authorization server

Calhoun et al. expires October 2001 [Page 63]

Internet-Draft May 2001
(if contacted) or the accounting server regarding the way accounting
data shall be forwarded. This information includes accounting record
timeliness requirements.

As discussed in [40], real-time transfer of accounting records is a
requirement, such as the need to perform credit limit checks and
fraud detection. Note that batch accounting is not a requirement, and
is therefore not supported by this extension. Diameter. Should Batched Accounting be
required in the future, a new Diameter extension application will need to be
created, or it could be handled using another protocol.

The authorization server (chain) directs the selection of proper
transfer strategy, based on its knowledge of the user and
relationships of roaming partnerships. The server (or proxies in
between) agents) uses
the Accounting-Interim-Interval AVP to control the operation of the
Diameter peer operating as a client. The Accounting-Interim-Interval
AVP, when present, instructs the Diameter node acting as a client to
produce accounting records continuously even during a session.

The Diameter accounting server MAY override the interim interval by
including an Accounting-Interim-Interval AVP in the Accounting-Answer
message. When the AVP is present, the latest value received SHOULD be
used in the generation of interim accounting messages.

12.2

11.2 Protocol Messages

A Diameter node that receives a successful authentication and/or
authorization messages from the Home AAA Server, MUST collect

Calhoun et al. expires December 2001 [Page 74]

Internet-Draft June 2001

accounting information for the session. The Accounting-Request
message is used to transmit the accounting information to the Home
AAA server, which MUST reply with the Accounting-Answer message to
confirm reception. The Accounting-Answer message includes the
Result-Code AVP, which MAY indicate that an error was present in the
accounting message. A rejected Accounting-Request message SHOULD
cause the user's session to be terminated.

Each Diameter Accounting protocol message MAY be compressed using
IPComp [41] in order to reduce the used network bandwidth, which MAY
use IKE [15] to negotiate the compression parameters.

12.3 Extension

11.3 Application document requirements

Each Service-Specific Diameter extension application (e.g. NASREQ, MobileIP), MUST define their
Service-Specific AVPs that MUST be present in the Accounting-Request
message in a section entitled "Accounting AVPs".

Calhoun et al. expires October 2001 [Page 64]

Internet-Draft May 2001 The extension application MUST
assume that the AVPs described in this document will be present in
all Accounting messages, so only their respective service-specific
AVPs need to be defined in this section.

12.4

11.4 Fault Resilience

Diameter Base protocol mechanisms are used to overcome small message
loss and network faults of temporary nature.

Diameter peers acting as clients MUST implement the use of failover
to guard against server failures and certain network failures.
Diameter peers acting as servers agents or related off-line processing
systems MUST detect duplicate accounting records caused by the
sending of same record to several servers and duplication of messages
in transit. This detection MUST be based on the inspection of the
Session-Id and Accounting-Record-Number AVP pairs.

Diameter clients MAY have non-volatile memory for the safe storage of
accounting records over reboots or extended network failures, network
partitions, and server failures. If such memory is available the
client SHOULD store new accounting records there as soon as the
records are created and until a positive acknowledgement of their
reception from the Diameter Server has been received. Upon a reboot,
the client MUST starting sending the records in the non-volatile
memory to the accounting server with appropriate modifications in
termination cause, session length, and other relevant information in
the records.

A further extension application of this protocol may include AVPs to control

Calhoun et al. expires December 2001 [Page 75]

Internet-Draft June 2001

how many accounting records may at most be stored in the Diameter
client without committing them to the non-volatile memory or
transferring them to the Diameter server.

The client SHOULD NOT remove the accounting data from any of its
memory areas before the correct Accounting-Answer has been received.
The client MAY remove oldest, undelivered or yet unacknowledged
accounting data if it runs out of resources such as memory. It is an
implementation dependent matter for the client to accept new sessions
under this condition.

12.5

11.5 Accounting Records

In all accounting records the Session-Id and User-Name AVPs MUST be
present. If strong end-to-end authentication is required, as described in
[11], the CMS-Data AVP may be used to authenticate the Accounting
Data and Service Specific AVPs. It is not typically necessary, nor

Calhoun et al. expires October 2001 [Page 65]

Internet-Draft May 2001
recommended, that the strong end-to-end authentication cover any additional
AVPs since the Data and Service Specific AVP, and associated CMS-Data, CMS-
Data, MAY need to be submitted to a third party.

Different types of accounting records are sent depending on the
actual type of accounted service and the authorization server's
directions for interim accounting. If the accounted service is a
one-time event, meaning that the start and stop of the event are
simultaneous, then the Accounting-Record-Type AVP MUST be present and
set to the value EVENT_RECORD.

If the accounted service is of a measurable length, then the AVP MUST
use the values START_RECORD, STOP_RECORD, and possibly,
INTERIM_RECORD. If the authorization server has directed interim
accounting to be enabled for the session, but no interim interval was
specified, two accounting records MUST be generated for each service
of type session. When the initial Accounting-Request is sent for a
given session is sent, the Accounting-Record-Type AVP MUST be set to
the value START_RECORD. When the last Accounting-Request is sent, the
value MUST be STOP_RECORD.

If a specified interim interval exists, the Diameter client MUST
produce additional records between the START_RECORD and STOP_RECORD,
marked INTERIM_RECORD. The production of these records is directed
both by Accounting-Interim-Interval as well as any re-authentication
or re-authorization of the session. The Diameter client MUST
overwrite any previous interim accounting records that are locally
stored for delivery, if a new record is being generated for the same
session. This ensures that only one pending interim record can exist
on an access device for any given session.

13.0

Calhoun et al. expires December 2001 [Page 76]

Internet-Draft June 2001

A particular value of Accounting-Session-Id MUST appear only in one
sequence of accounting records from a DIAMETER client, except for the
purposes of retransmission. Note that sometimes such sequence of
records is related to a higher-level session, possibly spanning
several DIAMETER clients. The linking of such record sequences
together lies, however, outside DIAMETER and is typically performed
by postprocessing systems. It is the responsibility of the particular
Diameter application specification to define a sufficient set of AVPs
so that this correlation can be done based on, for instance, IP
addresses. Likewise, the application specifications MUST also define
the exact concept of a session that is being accounted. For
instance, the NASREQ DIAMETER application treats a single PPP
connection to a Network Access Server as one session.

The one sequence that is sent MUST be either one record with
Accounting-Record-Type AVP set to the value EVENT_RECORD, or several
records starting with one having the value START_RECORD, followed by
zero or more INTERIM_RECORD, and a single STOP_RECORD. That is, it is
not allowed to mix record types, such as sending interim records
followed by an event record. A particular Diameter application
specification MUST define which kind of sequences should be used.

12.0 Accounting Command-Codes

This section defines new Command-Code values that MUST be supported
by all Diameter implementations that provide Accounting services.

13.1

12.1 Accounting-Request (ACR) Command

The Accounting-Request command, indicated by the Command-Code field
set to 271 and the message flags' Command Flags' 'R' bit set, is sent by a Diameter
node, acting as a client, in order to exchange accounting information
with a peer.

When the Accounting-Request is being submitted to a broker, third party (e.g.
settlement service), and includes the CMS-Data AVP [11], the CMS-Data
AVP MUST be signed by both the local and home Diameter server using
the countersignature

Calhoun et al. expires October 2001 [Page 66]

Internet-Draft May 2001 procedures described in [11].

The AVP listed below SHOULD include service specific accounting AVPs,
as described in section 12.3. 11.3.

Calhoun et al. expires December 2001 [Page 77]

Internet-Draft June 2001

Message Format

<Accounting-Request> ::= < Diameter Header: 271, R REQUEST >
< Session-Id >
{ Acct-Extension-Id Acct-Application-Id }
{ User-Name }
{ Origin-FQDN Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
{ Accounting-Session-Id }
[ Accounting-Interim-Interval ]
[ Max-Wait-Time Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

13.2

12.2 Accounting-Answer (ACA) Command

The Accounting-Answer command, indicated by the Command-Code field
set to 271 and the message flags' 'A' Command Flags' 'R' bit set, cleared, is used to
acknowledge an Accounting-Request command. The Accounting-Answer
command contains the same Session-Id and MAY contains the same
Accounting Description and Usage AVPs that were sent in the
Accounting-Request command. If the CMS-Data AVP was present in the
Accounting-Request, the corresponding ACA message MUST include the
CMS-Data AVP signed by the
responder to provide strong AVP authentication, which MAY be used for
the purposes of repudiation.

Only the target Diameter Server, known as the home Diameter Server,
SHOULD respond with the Accounting-Answer command.

The AVP listed below SHOULD include service specific accounting AVPs,
as described in section 12.3.

Calhoun et al. expires October 2001 [Page 67]

Internet-Draft May 2001

Message Format

<Accounting-Answer> ::= < Diameter Header: 271, A >
< Session-Id >
{ Acct-Extension-Id }
{ User-Name }
{ Result-Code }
{ Origin-FQDN }
{ Origin-Realm }
{ Destination-FQDN }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
{ Accounting-Session-Id }
[ Error-Reporting-FQDN ]
[ Accounting-Interim-Interval ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

13.3 Accounting-Status-Ind (ASI) Command

The Accounting-Status-Ind command, indicated by the Command-Code
field set to 279 and the message flags' 'I' bit set, is sent by a
Diameter node in order to inform its peer of whether Accounting
messages will be sent in the future. A Diameter node that is about to
be taken out of service SHOULD issue an Accounting-Status-Ind
message, with the Accounting-State AVP set to DISABLED. Prior to
sending such a message, every attempt SHOULD be made to transmit any
pending accounting messages.

A Failed ASI would contain the same Command-Code, but would require
that only be 'F' bit AVP signed by the responder to provide strong AVP
authentication, which MAY be set.

A used for the purposes of repudiation.

Only the target Diameter node that detected that it is able to issue Accounting
messages MUST issue an Accounting-Status-Ind message, Server, known as the home Diameter Server,
SHOULD respond with the
Accounting-State Accounting-Answer command.

The AVP set to ENABLED. listed below SHOULD include service specific accounting AVPs,
as described in section 11.3.

Calhoun et al. expires October December 2001 [Page 68] 78]

Internet-Draft May June 2001

Message Format

<Accounting-Status-Ind>

<Accounting-Answer> ::= < Diameter Header: 279, I 271, A >
< Session-Id >
{ Acct-Extension-Id Acct-Application-Id }
{ User-Name }
{ Result-Code }
{ Origin-FQDN Origin-Host }
{ Origin-Realm }
{ Destination-Realm Destination-Host }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
{ Accounting-State Accounting-Session-Id }
[ Error-Reporting-Host ]
[ Accounting-Interim-Interval ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

13.4

12.3 Accounting-Poll-Ind (API) Command

The Accounting-Poll-Ind command, indicated by the Command-Code field
set to 273 and the message flags' 'I' bit set, is sent by a Diameter
Server in order to force the peer to send current accounting data.
This data MUST include not yet sent accounting records from completed
sessions, as well as INTERIM_RECORD records from all ongoing
sessions.

A Failed API would contain the same Command-Code, but would require
that only be 'F' bit be set.

Diameter implementations MAY support the Accounting-Poll-Ind command.
An implementation still conforms to this specification if API is not
supported.

The receiver MUST use the Accounting-Request command to send the
accounting data.

The use of Accounting-Poll-Ind is useful in situations where a
Diameter server comes up after an unscheduled downtime, and wishes to
synchronize with the client(s) sooner than at the end of the next
INTERIM_RECORD or at the end of a session.

Warning: The use of the Accounting-Poll-Ind message is discouraged in
roaming networks, since it is unfeasible for a server to attempt to
poll all of it's roaming partner's Diameter peers.

Calhoun et al. expires October December 2001 [Page 69] 79]

Internet-Draft May June 2001

Message Format

<Accounting-Poll-Ind> ::= < Diameter Header: 273, I >
< Session-Id >
{ Acct-Extension-Id Acct-Application-Id }
{ Destination-FQDN Destination-Host }
{ Origin-FQDN Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Session-Id }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

14.0

13.0 Accounting AVPs

This section contains AVPs that describe accounting usage information
related to a specific session.

14.1

13.1 Accounting-Record-Type AVP

The Accounting-Record-Type AVP (AVP Code 480) is of type Unsigned32
and contains the type of accounting record being sent. The following
values are currently defined for the Accounting-Record-Type AVP:

EVENT_RECORD 1
An Accounting Event Record is used to indicate that a one-time
event has occurred (meaning that the start and end of the event
are simultaneous). This record contains all information
relevant to the service, and is the only record of the service.

START_RECORD 2
An Accounting Start, Interim, and Stop Records are used to
indicate that a service of a measurable length has been given.
An Accounting Start Record is used to initiate an accounting
session, and contains accounting information that is relevant
to the initiation of the session.

INTERIM_RECORD 3
An Interim Accounting Record contains cumulative accounting
information for an existing accounting session. Interim
Accounting Records SHOULD be sent every time a re-
authentication or re-authorization occurs. Further, additional
interim record triggers MAY be defined by application-specific
Diameter extensions. applications. The selection of whether to use
INTERIM_RECORD records is directed by the Accounting-Interim-

Calhoun et al. expires October December 2001 [Page 70] 80]

Internet-Draft May June 2001

INTERIM_RECORD records is directed by the Accounting-Interim-
Interval AVP.

STOP_RECORD 4
An Accounting Stop Record is sent to terminate an accounting
session and contains cumulative accounting information relevant
to the existing session.

14.2

13.2 Accounting-Interim-Interval AVP

The Accounting-Interim-Interval AVP (AVP Code 482) is of type
Unsigned32 and is sent from the Diameter authenticating/authorizing home authorization server to
the Diameter client. The client uses information in this AVP to
decide how and when to produce accounting records. With different
values in this AVP, service sessions can result in one, two, or two+N
accounting records, based on the needs of the home-
organization. home-organization. The
following accounting record production behavior is directed by the
inclusion of this AVP:

1. The omission of the Accounting-Interim-Interval AVP or its
inclusion with Value field set to 0 means that EVENT_RECORD,
START_RECORD, and STOP_RECORD are produced, as appropriate for
the service.

2. The inclusion of the AVP with Value field set to a non-zero
value means that INTERIM_RECORD records MUST be produced
between the START_RECORD and STOP_RECORD records. The Value
field of this AVP is the nominal interval between these records
in seconds. The Diameter node that originates the accounting
information, known as the client, MUST produce the first
INTERIM_RECORD record roughly at the time when this nominal
interval has elapsed from the START_RECORD, the next one again
as the interval has elapsed once more, and so on until the
session ends and a STOP_RECORD record is produced.

The client MUST ensure that the interim record production times
are randomized so that large accounting message storms are not
created either among records or around a common service start
time.

14.3

13.3 Accounting-Record-Number AVP

The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32
and identifies this record within one session. As Session-Id AVPs are
globally unique, the combination of Session-Id and Accounting-
Record-Number AVPs is also globally unique, and can be used in
matching accounting records with confirmations. An easy way to

Calhoun et al. expires October December 2001 [Page 71] 81]

Internet-Draft May June 2001

produce unique numbers is to set the value to 0 for

matching accounting records of type
EVENT_RECORD and START_RECORD, and set the value to 1 for the first
INTERIM_RECORD, 2 for the second, and so on until the value for
STOP_RECORD is one more than for the last INTERIM_RECORD.

14.4 Accounting-State AVP

The Accounting-State AVP (AVP Code 486) is of type Unsigned32 and is
used to communicate to a peer whether Accounting messages will be
sent in the future. A node that issues an ASI with the Accounting-
State AVP set to DISABLED is informing its peer that it will no
longer be transmitting Accounting messages until a subsequent ASI
message confirmations. An easy way to
produce unique numbers is sent with to set the Accounting-State AVP value to 0 for records of type
EVENT_RECORD and START_RECORD, and set the value to ENABLED.

The following values have been defined: 1 ENABLED for the first
INTERIM_RECORD, 2 DISABLED

14.5 for the second, and so on until the value for
STOP_RECORD is one more than for the last INTERIM_RECORD.

13.4 Accounting-Session-Id AVP

The Accounting-Session-Id AVP (AVP Code 44) is of type OctetString,
and SHOULD be encoded in UTF-8 format [13]. [13], following the format
specified in section 10.3. The Accounting-Session-Id is not used by
the Diameter protocol, since the Session-Id defined in [1] is used
for both authentication/authorization and accounting purposes.
However, a RADIUS/Diameter gateway MAY need to include the
Accounting-Session-Id in Diameter accounting messages.

15.0

13.5 Accounting-Multi-Session-Id AVP

The Accounting-Multi-Session-Id AVP (AVP Code 50) is of type
OctetString and SHOULD be encoded in UTF08 format [13], following the
format specified in section 10.3. The Accounting-Multi-Session-Id AVP
is used to link together multiple related accounting sessions, where
each session would have a unique Accounting-Session-Id, but the same
Acounting-Multi-Session-Id AVP. This AVP MAY be returned by the
Diameter server in an authorization answer, and MUST be used in all
accounting messages for the given session.

14.0 AVP Occurrence Table

The following tables presents the AVPs defined in this document, and
specifies in which Diameter messages they MAY, or MAY NOT be present.
Note that AVPs that can only be present within a Grouped AVP are not
represented in this table.

The table uses the following symbols:
0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the
message.
0-1 Zero or one instance of the AVP MAY be present in the
message. It is considered an error if there are more than
once instance of the AVP.
1 One instance of the AVP MUST be present in the message.
1+ At least one instance of the AVP MUST be present in the
message.

Calhoun et al. expires October December 2001 [Page 72] 82]

Internet-Draft May June 2001

15.1

14.1 Base Protocol Command AVP Table

The table in this section is limited to the non-accounting Command
Codes defined in this specification.
+---------------------------+
+-----------------------------------+
| Command-Code |
|---+---+---+---+---+---+---+
|---+---+---+---+---+---+---+---+---+
Attribute Name |DRI|DSI|DWR|DWA|STI|STR|STA|
------------------------------|---+---+---+---+---+---+---|
Acct-Extension-Id |CER|CEA|MRA|DWR|DWA|ASR|ASA|STR|STA|
------------------------------|---+---+---+---+---+---+---+---+---|
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |
Auth-Extension-Id
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |
Authorization-Lifetime |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Destination-FQDN |0-1|0-1|0-1|1
Destination-Host |0-1|0-1|1 |0-1|1 |1 |1 |0-1|1 |
Destination-Realm |0 |0 |0 |0 |1 |1 |0 |
DSI-Event |0 |1 |0 |0 |0 |0 |1 |0 |
Error-Message |0 |0 |0 |0 |0 |0 |0-1|0 |0 |
Error-Reporting-FQDN
Error-Reporting-Host |0 |0 |0 |0 |0 |0 |0-1|0 |0 |
Failed-AVP |0 |0+ |0+ |0 |0+ |0 |0+ |0 |0+ |
Firmware-Revision |0-1|0 |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |
Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |
Max-Wait-Time |0 |0 |0+ |0 |0 |0 |0 |
Origin-FQDN
Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |
Proxy-Info |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |
Redirect-Host |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Result-Code |0 |0 |1 |1 |0 |1 |0 |0 |0 |1 |
Route-Record |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |
Session-Id |0 |0-1|0 |0 |1 |0 |0 |1 |1 |1 |1 |
Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Origin-State-Id |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
Supported-Vendor-Id |0+ |0 |0 |0 |0 |0 |0 |0 |0 |
Termination-Cause |0 |0 |0 |0 |0 |0 |0 |1 |0 |
User-Name |0 |0 |0 |0 |0 |1 |1 |1 |1 |
Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |
------------------------------|---+---+---+---+---+---+---|

15.2
Vendor-Specific-Application-Id|0+ |0+ |0 |0 |0 |0 |0 |0 |0 |
------------------------------|---+---+---+---+---+---+---+---+---|

14.2 Accounting AVP Table

The table in this section is used to represent which AVPs defined in
this document are to be present in the Accounting messages.

Calhoun et al. expires October December 2001 [Page 73] 83]

Internet-Draft May June 2001

+-----------------------+

+-----------------+
| Command-Code |
|-----+-----+-----+-----+
|-----+-----+-----+
Attribute Name | ACR | ACA | ASI | API |
------------------------------|-----+-----+-----+-----+
------------------------------|-----+-----+-----+
Accounting-Interim-Interval | 0-1 | 0-1 | 0 |
Accounting-Multi-Session-Id | 0-1 | 0-1 | 0 |
Accounting-Record-Number | 1 | 1 | 0 | 0 |
Accounting-Record-Type | 1 | 1 | 0 | 0 |
Accounting-Session-Id | 1 | 1 | 0 | 1 |
Accounting-State | 0 | 0 | 1 | 0 |
Acct-Extension-Id
Acct-Application-Id | 1 | 1 | 1 | 1 |
Destination-FQDN
Destination-Host | 0+ | 1 | 0+ | 0-1 |
Destination-Realm | 1 | 0 | 1 | 1 |
Error-Reporting-FQDN
Error-Reporting-Host | 0 | 0+ | 0 | 0 |
Max-Time-Wait | 0+ | 0 | 0 | 0 |
Origin-FQDN | 1
Origin-Host | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Proxy-Info | 0+ | 0+ | 0+ | 0 |
Route-Record | 0+ | 0+ | 0+ | 0+ |
Result-Code | 0 | 1 | 0 | 0 |
Session-Id | 1 | 1 | 0 | 1 |
------------------------------|-----+-----+-----+-----+

16.0
------------------------------|-----+-----+-----+

15.0 IANA Considerations

This document defines a number of assigned numbers to be maintained
by the IANA. This section explains the criteria to be used by the
IANA to assign additional numbers in each of these lists. The
following subsections describe the assignment policy for the
namespaces defined elsewhere in this document.

16.1

15.1 AVP

As defined in section 4.0, the AVP header contains two fields that
requires IANA namespace management; the AVP Code and Flags field.

16.1.1

15.1.1 AVP Code

the AVP Code namespace is used to identify attributes. When the
Vendor ID value is set to zero (0), IANA will maintain a registry of
assigned AVP codes, and in some cases also their values. AVP Codes
0-254 are managed separately as RADIUS Attribute Types [46], while
the remaining namespace is available for assignment through
Designated Expert via Specification
Required [12].

Calhoun et al. expires October December 2001 [Page 74] 84]

Internet-Draft May June 2001

Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP
header is set to a non-zero value, is for Private Use.

This document defines the AVP Codes 257-259, 262-269, 271, 277-284,
291-297, 257-260, 263-269, 278-284, 291-
297, 480, 482 and 485-486. See section 4.5 for the assignment of the
namespace in this specification.

16.1.2

15.1.2 AVP Flags

There are 16 bits in the AVP Flags field of the AVP header, defined
in section 4.0. This document assigns bit 1 ('M'andatory), bit 3
('V'endor Specific) and bit 5 ('P'rotected). The remaining bits
should only be assigned via a Standards Action [12].

16.2

15.2 Diameter Header

As defined in section 3.0, the Diameter header contains two fields
that require IANA namespace management; Command Code and Message Command
Flags.

16.2.1

15.2.1 Command Codes

The Command Code namespace is used to identify Diameter commands.
The values 0-255 are reserved for RADIUS backward compatibility, and
are defined as "RADIUS Packet Type Codes" in [46]. The remaining
values are available via Standards Action [12].

Vendor-Specific Command Codes, where the Vendor-Id field in the
Diameter header is set to a non-zero value, is for Private Use.

This document defines the Command Codes 257, 271, 273-275, 279-280 280 and
282. See section 3.1 for the assignment of the namespace in this
specification.

16.2.2 Message

15.2.2 Command Flags

There are thirteen eight bits in the Command Flags field of the Diameter
header. This document assigns bit 1 ('R'esponse), bit 2 ('I'nterrogation) and
bit 3 ('E'xpected Reply). 8 ('R'equest). Bits 4 1 through 13 should 7
MUST only be assigned via a Standards Action [12].

16.3 Extension

15.3 Application Identifiers

Calhoun et al. expires October 2001 [Page 75]

Internet-Draft May 2001

As defined in section 6.1, the Extension Application Identifier is used to

Calhoun et al. expires December 2001 [Page 85]

Internet-Draft June 2001

identify a specific Diameter Extension. Application. All values, other than zero
(0) are available for assignment via Standards Action [12].

Note that the Diameter protocol is not intended to be extended for
any purpose. Any extensions applications defined MUST ensure that they fit
within the existing framework, and that no changes to the base
protocol are required.

16.4

15.4 Result-Code AVP Values

As defined in Section 9.1.1, 9.1, the Result-Code AVP (AVP Code 268) defines
the values 1001, 2001, 4001-4003 and 5001-5013.

All remaining values are available for assignment via IETF Consensus
[12].

16.5 DSI-Event AVP Values

As defined in Section 9.2.2, the DSI-Event AVP (AVP Code 297) defines
the values 1001, 3001, 4001 and 5001-5008. 5001-5015.

All remaining values are available for assignment via IETF Consensus
[12].

16.6 Accounting-State

15.5 Accounting-Record-Type AVP Values

As defined in Section 14.4, 13.1, the Accounting-State Accounting-Record-Type AVP (AVP Code 486)
480) defines the values 1-2. 1-4. All remaining values are available for
assignment via IETF Consensus [12].

16.7 Accounting-Record-Type

15.6 Termination-Cause AVP Values

As defined in Section 14.1, 10.9, the Accounting-Record-Type Termination-Cause AVP (AVP Code
480) 295)
defines the values 1-4. 1-5. All remaining values are available for
assignment via IETF Consensus [12].

16.8

15.7 Diameter TCP/SCTP Port Numbers

An IANA request has been placed for TCP and SCTP port numbers. The
IANA has informed the authors that "TBD" should be used in section
2.1 this document, and will be updated by the RFC editor during the
RFC publication process.

Calhoun et al. expires October 2001 [Page 76]

Internet-Draft May 2001

17.0 Open Issues

The following are the open issues that SHOULD be addressed

IANA should also replace "TBD" in future
versions of the Diameter protocol:

- AVPs with time values are represented by Unsigned32 type data.
This value is a timestamp consistent section 2.7 with NTP [18]. This field
is expected to expire sometime the port number
assigned in 2038. Future investigation
SHOULD be done to determine if a 64 bit time format could be
used.

18.0 section 2.1

16.0 Diameter protocol related configurable parameters

This section contains the configurable parameters that are found
throughout this document:

Calhoun et al. expires December 2001 [Page 86]

Internet-Draft June 2001

Diameter Peer
A Diameter entity MAY communicate with peers that are
statically configured. A statically configured Diameter peer
would require that either the IP address or the fully qualified
domain name (FQDN) be supplied, which would then be used to
resolve through DNS.

Realm Routing Table
A Diameter Proxy server routes messages based on the realm
portion of a Network Access Identifier (NAI). The server MUST
have a table of Realms Names, and the address of the peer to
which the message must be forwarded to. The routing table MAY
also include a "default route", which is typically used for all
messages that cannot be locally processed.

RTT-Multiplier

Tc timer
The Round Trip Time Multiplier is used Tc timer controls the frequency that transport connection
attempts are done to determine when a DWR
message is to be sent to an inactive peer. peer with whom no active transport
connection exists. The recommended
valus value is 4.

Watchdog Interval Period 30 seconds.

Tw timer
The Watchdog Interval Period is Tw timer controls the frequency at which DWR the watchdog messages are
to be sent to inactive peers. The recommended value is 30
seconds.

19.0

17.0 Security Considerations

The Diameter base protocol assumes that messages are secured by using
either IP Security, or TLS. This security model is acceptable in
environments where there are no untrusted third party Diameter

Calhoun et al. expires October 2001 [Page 77]

Internet-Draft May 2001

brokers, relay, proxy,
or redirect servers.

When third party brokers or redirect servers are used, strong
application level security SHOULD be required, such as non-
repudiation. When the communicating peers do require this level of
security either for legal or business purposes, the extension Diameter
application defined in [11] MAY be used. This security model provides
AVP-level authentication, and the encryption mechanism is designed
such that only the target host has the keying information required to
decrypt the information.

20.0

18.0 References

[1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti-
cation Dial In User Service (RADIUS)", RFC 2865, June 2000. 2000.

Calhoun et al. expires December 2001 [Page 87]

Internet-Draft June 2001

[2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994.

[3] Postel, "User Datagram Protocol", RFC 768, August 1980.

[4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.

[5] Kaufman, Perlman, Speciner, "Network Security: Private Communi-
cations in a Public World", Prentice Hall, March 1995, ISBN 0-
13-061466-1.

[6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
Authentication", RFC 2104, January 1997.

[7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ
Extension", draft-ietf-aaa-diameter-nasreq-04.txt,
Application", draft-ietf-aaa-diameter-nasreq-05.txt, IETF work
in progress, May June 2001.

[8] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu-
ary 1999.

[10] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft-
ietf-aaa-diameter-mobileip-04.txt, Application",
draft-ietf-aaa-diameter-mobileip-05.txt, IETF work in progress, May
June 2001.

[11] P. Calhoun, W. Bulley, S. Farrell, "Diameter End-2-End CMS Security
Extension", draft-ietf-aaa-diameter-e2e-sec-04.txt appli-
cation", draft-ietf-aaa-diameter-cms-sec-00.txt (work in pro-
gress), May June 2001.

[12] Narten, Alvestrand,"Guidelines for Writing an IANA

Calhoun et al. expires October 2001 [Page 78]

Internet-Draft May 2001

Considerations Considera-
tions Section in RFCs", BCP 26, RFC 2434, October 1998

[13] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public
Key Infrastructure Online Certificate Status Protocol (OCSP)",
RFC 2560, June 1999.

[15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC
2409, November 1998.

[16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC
2373, July 1998.

[17] ISI, "Internet Protocol", RFC 791, September 1981.

[18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4,

Calhoun et al. expires December 2001 [Page 88]

Internet-Draft June 2001

IPv6 and OSI, RFC 2030, October 1996.

[19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras-
tructure Certificate and CRL Profile", RFC 2459, January 1999.

[20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols",
RFC 2477, January 1999.

[21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access
Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work
in progress, June 2000.

[22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA",
draft-hiller-cdma2000-aaa-02.txt, IETF work in progress, Sep-
tember 2000.

[23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
Authorization, and Accounting Requirements". RFC 2977. October
2000.

[24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.

[25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)." RFC 2284, March 1998.

[26] R. Stewart et al., "Stream Control Transmission Protocol". RFC
2960. October 2000.

[27] Postel, J. "Transmission Control Protocol", RFC 793, January

Calhoun et al. expires October 2001 [Page 79]

Internet-Draft May 2001
1981.

[28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location
Protocol, Version 2", RFC 2165, June 1999.

[29] P. Calhoun, "Diameter T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, "Uniform
Resource Management", draft-calhoun-
diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. Identifiers (URI): Generic Syntax". RFC 2396, August
1998.

[30] Institute of Electrical and Electronics Engineers, "IEEE Stan-
dard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard
754-1985, August 1985.

[31] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifica-
tions: ABNF", RFC 2234, November 1997.

[32] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Ser-
vice: Schemes", RFC 2609, June 1999.

Calhoun et al. expires December 2001 [Page 89]

Internet-Draft June 2001

[33] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying
the location of services (DNS SRV)", RFC 2782, February 2000.

[34] D. Eastlake, "Domain Name System Security Extensions", RFC 2535,
March 1999.

[35] D. Eastlake, "DNS Security Operational Considerations", RFC
2541, March 1999.

[36] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s
)", RFC 2931, September 2000.

[37] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.

[38] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.

[39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp.
677-680.

[40] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting
Management", RFC 2975, October 2000.

[41] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 2393, December 1998.

[42] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD
51, July 1994.

Calhoun et al. expires October 2001 [Page 80]

Internet-Draft May 2001

[43] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming
Implementations", RFC 2194, September 1997.

[44] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementa-
tion in Roaming", RFC 2607, June 1999.

[45] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.

[46] IANA, "RADIUS Types", http://www.isi.edu/in-
notes/iana/assignments/radius-types

21.0

19.0 Acknowledgements

The authors would like to thank Nenad Trifunovic, Tony Johansson and
Pankaj Patel for their participation in the pre-IETF Document Reading
Party. Allison Mankin's Mankin's, Jonathan Wood and Bernard Aboba's assistance

Calhoun et al. expires December 2001 [Page 90]

Internet-Draft June 2001

was invaluable in working out transport issues, and similarly with
Steven Bellovin's help in the security area.

Paul Funk and David Mitton were instrumental in getting the Peer
State Machine correct, and our deep thanks go to them for their time.
Text in this document was also provided by Paul Funk, Mark Eklund,
Mark Jones and Dave Spence.

The authors would also like to acknowledge the following people for
their contribution in the development of the Diameter protocol:

Bernard Aboba,

William Bulley, Mark Eklund, David Frascone, Daniel C. Fox, Lol Grant, Ignacio
Goyret, Nancy Greene, Peter Heitman, Fredrik Johansson, Mark Jones,
Martin Julien, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Mus-
lin, Kenneth Peirce, Stephen Farrell, Sumit Vakil, John R. Vollbrecht, Vollbrecht
and Jeff Weisberg and Jonathan Wood

22.0

20.0 Authors' Addresses

Questions about this memo can be directed to:

Pat R. Calhoun
Network and Security Research Center, Sun Laboratories
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 et al. expires October 2001 [Page 81]

Internet-Draft May 2001

Haseeb Akhtar
Wireless Technology Labs
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082-4399
USA

Phone: +1 972-684-8850
E-Mail: haseeb@nortelnetworks.com

Calhoun et al. expires December 2001 [Page 91]

Internet-Draft June 2001

Jari Arkko
Oy LM Ericsson Ab
02420 Jorvas
Finland

Phone: +358 40 5079256
E-Mail: Jari.Arkko@ericsson.com

Erik Guttman
Solaris Advanced Development
Sun Microsystems, Inc.
Eichhoelzelstr. 7
74915 Waibstadt
Germany

Phone: +49-7263-911-701
E-mail: erik.guttman@germany.sun.com

Allan C. Rubens
Tut Systems, Inc.
220 E. Huron, Suite 260
Ann Arbor, MI 48104
USA

Phone: +1 734-995-1697
E-Mail: arubens@tutsys.com

Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
USA

Phone: +1 425 438 8218

Calhoun et al. expires October 2001 [Page 82]

Internet-Draft May 2001

23.0

21.0 Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are

Calhoun et al. expires December 2001 [Page 92]

Internet-Draft June 2001

included on all such copies and derivative works. However, this docu-
ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. The lim-
ited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns. This document
and the information contained herein is provided on an "AS IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

24.0

22.0 Expiration Date

This memo is filed as <draft-ietf-aaa-diameter-04.txt> <draft-ietf-aaa-diameter-05.txt> and expires in
October
December 2001.

Calhoun et al. expires October December 2001 [Page 83] 93]

Internet-Draft May June 2001

Appendix A. Diameter Service Template

The following service template describes the attributes used by Diam-
eter servers to advertise themselves. This simplifies the process of
selecting an appropriate server to communicate with. A Diameter
client can request specific Diameter servers based on characteristics
of the Diameter service desired (for example, an AAA server to use
for accounting.)

Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com>
Language of service template: en

Security Considerations:
Diameter clients and servers use various cryptographic mechanisms
to protect communication integrity, confidentiality as well as
perform end-point authentication. It would thus be difficult if
not impossible for an attacker to advertise itself using SLPv2 and
pose as a legitimate Diameter peer without proper preconfigured
secrets or cryptographic keys. Still, as Diameter services are
vital for network operation it is important to use SLPv2 authenti-
cation to prevent an attacker from modifying or eliminating ser-
vice advertisements for legitimate Diameter servers.

Template text:
-------------------------template begins here-----------------------
template-type=service:diameter

template-version=0.0

template-description=
The Diameter protocol is defined by draft-ietf-aaa-diameter-04.txt

template-url-syntax=
url-path= ; The standard service diameter URL syntax format is used. described in section 2.7.
; For example: 'service:diameter://aaa.example.com:1812 Example: 'diameter://aaa.example.com:1812;transport=tcp

Calhoun et al. expires October December 2001 [Page 84] 94]

Internet-Draft May June 2001

supported-extensions=

supported-auth-applications= string L M
# This attribute lists the Diameter extensions applications supported by the
# AAA implementation. The extensions applicationss currently defined are:
# Extension Application Name Defined by
# --------------- ---------------- -----------------------------------
# NASREQ draft-ietf-aaa-diameter-nasreq-04.txt
# MobileIP draft-ietf-aaa-diameter-mobileip-04.txt
# End-to-End CMS Security draft-ietf-aaa-diameter-e2e-sec-02.txt draft-ietf-aaa-diameter-cms-sec-00.txt
# Resource Management draft-calhoun-diameter-res-mgmt-06.txt
# Notes:
# . Diameter implementations support one or more applications.
# . Additional applications may be defined in the future.
# An updated service template will be created at that time.
#
NASREQ,MobileIP,CMS Security

supported-acct-applications= string L M
# This attribute lists the Diameter applications supported by the
# AAA implementation. The applicationss currently defined are:
# Application Name Defined by
# ---------------- -----------------------------------
# NASREQ draft-ietf-aaa-diameter-nasreq-04.txt
# MobileIP draft-ietf-aaa-diameter-mobileip-04.txt
# CMS Security draft-ietf-aaa-diameter-cms-sec-00.txt
#
# Notes:
# . Diameter implementations support one or more extensions. applications.
# . Additional extensions applications may be defined in the future.
# An updated service template will be created at that time.
#
NASREQ,MobileIP,Accounting,End-to-End Security,Resource Management
NASREQ,MobileIP,CMS Security

supported-transports= string L M
SCTP
# This attribute lists the supported transports that the Diameter
# implementation accepts. Note that a compliant Diameter
# implementation MUST support SCTP, though it MAY support other
# transports, too.
SCTP,TCP

-------------------------template ends here-----------------------

Calhoun et al. expires October December 2001 [Page 85] 95]

----