WDIFF

draft-ietf-aaa-diameter-06.txt --> draft-ietf-aaa-diameter-07.txt

AAA Working Group Pat R. Calhoun
Internet-Draft Sun Microsystems, Inc.
Category: Standards Track Haseeb Akhtar
<draft-ietf-aaa-diameter-06.txt>
<draft-ietf-aaa-diameter-07.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.
June
July 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 January 2002 [Page 1]

Internet-Draft June July 2001

Abstract

The Diameter base protocol is intended to provide a AAA framework for
Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message
format, transport, error reporting and security services to be used
by all Diameter applications and MUST be supported by all Diameter
implementations.

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 Applications
2.3.4 Application authentication procedures
2.4 Diameter Applications Application Compliance
2.5 Application Identifiers
2.6 Peer Table
2.7 Realm-Based Routing Table
2.8 Role of Diameter Agents
2.5.1
2.8.1 Relay Agents
2.5.2
2.8.2 Proxy Agents
2.5.3
2.8.3 Redirector Agents
2.5.4
2.8.4 Translation Agents
2.6 Diameter Server Discovery
3.0 Diameter Header
3.1 Command Code Definitions
3.2 Command Code ABNF specification
3.3 Diameter Command Naming Conventions
4.0 Diameter AVPs
4.1 AVP Header
4.2 Optional Header Elements
4.3 AVP Data Formats
4.4 Derived AVP Data Formats
4.5 Grouped AVP Values
4.5.1 Example AVP with a Grouped Data type
4.6 Diameter Base Protocol AVPs
5.0 Diameter Peers
5.1 Connecting to Peers
5.2 Diameter Peer Discovery

Calhoun et al. expires January 2002 [Page 2]

Internet-Draft July 2001

5.3 Capabilities Negotiation
5.3.1 Capabilities-Exchange-Request
5.3.2 Capabilities-Exchange-Answer
5.3.3 Vendor-Id AVP
5.3.4 Firmware-Revision AVP
5.3.5 Host-IP-Address AVP
5.3.6 Supported-Vendor-Id AVP
5.3.7 Product-Name AVP
5.3.8 Alternate-Peer AVP
5.4 Disconnecting Peer connections
5.4.1 Disconnect-Peer-Request
5.4.2 Disconnect-Peer-Answer
5.4.3 Disconnect-Cause AVP
5.5 Transport Failure Detection
5.5.1 Device-Watchdog-Request
5.5.2 Device-Watchdog-Answer
5.5.3 Transport Failure Algorithm
5.5.4 Failover/Failback Procedures
5.6 Peer State Machine
5.6.1 Incoming connections
5.6.2 Events
5.6.3 Actions
5.6.4 The Election Process
6.0 Diameter message processing
5.1
6.1 Diameter request routing overview
5.1.1
6.1.1 Originating a Request
5.1.2
6.1.2 Sending a Request
5.1.3
6.1.3 Receiving Requests
6.1.4 Processing Local Requests

Calhoun et al. expires December 2001 [Page 2]

Internet-Draft June 2001

5.1.4
6.1.5 Request Forwarding
5.1.5 Peer Table
5.1.6
6.1.6 Request Routing
5.1.7 Realm-Based Routing Table
5.1.8
6.1.7 Redirecting requests
5.1.9
6.1.8 Relaying and Proxying Requests
5.2
6.1.9 Relaying and Proxying Server-Initiated Requests
6.2 Diameter Answer Processing
5.2.1
6.2.1 Processing received Answers
5.2.2
6.2.2 Relaying and Proxying Answers
5.3
6.3 Hiding Network Topology
5.4
6.4 Origin-Host AVP
5.5
6.5 Origin-Realm AVP
5.6
6.6 Destination-Host AVP
5.7
6.7 Destination-Realm AVP
5.8
6.8 Routing AVPs
5.8.1
6.8.1 Route-Record AVP
5.8.2
6.8.2 Proxy-Info AVP
5.8.3
6.8.3 Proxy-Host AVP
5.8.4
6.8.4 Proxy-State AVP
5.9 Redirect-Host AVP
5.10 Redirect-Host-Usage AVP
5.11 Redirect-Max-Cache-Time AVP
6.0 Capabilities Negotiation
6.1 Application Identifiers
6.2 Capabilities-Exchange-Request
6.3 Capabilities-Exchange-Answer
6.4 Vendor-Id AVP
6.5 Firmware-Revision AVP
6.6 Auth-Application-Id AVP
6.7 Host-IP-Address AVP
6.8 Supported-Vendor-Id
6.8.5 Source-Route AVP

Calhoun et al. expires January 2002 [Page 3]

Internet-Draft July 2001

6.9 Product-Name Auth-Application-Id AVP
6.10 Acct-Application-Id AVP
6.11 Vendor-Specific-Application-Id AVP
6.12 Redirect-Host AVP
6.13 Redirect-Host-Usage AVP
6.14 Redirect-Max-Cache-Time 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
8.1 Incoming connections
8.2 Events
8.3 Actions
8.4 The Election Process
9.0 Error Handling
9.1
7.1 Result-Code AVP
9.1.1
7.1.1 Informational
9.1.2
7.1.2 Success
9.1.3
7.1.3 Protocol Errors

Calhoun et al. expires December 2001 [Page 3]

Internet-Draft June 2001

9.1.4
7.1.4 Transient Failures
9.1.5
7.1.5 Permanent Failures
9.2 Message-Reject-Answer
9.3
7.2 Error Bit
7.3 Error-Message AVP
9.4
7.4 Error-Reporting-Host AVP
9.5
7.5 Failed-AVP AVP
10.0
8.0 Diameter User Sessions
10.1
8.1 Authorization Session State Machine
10.2
8.2 Accounting Session State Machine
10.3
8.3 Server-Initiated Re-Auth
10.3.1
8.3.1 Re-Auth-Request
10.3.2
8.3.2 Re-Auth-Answer
10.4
8.4 Session Termination
10.4.1
8.4.1 Session-Termination-Request
10.4.2
8.4.2 Session-Termination-Answer
10.5
8.5 Aborting a Session
10.5.1
8.5.1 Abort-Session-Request
10.5.2
8.5.2 Abort-Session-Answer
10.6
8.6 Inferring Session Termination from Origin-State-Id
10.7
8.7 Auth-Request-Type AVP
8.8 Session-Id AVP
10.8
8.9 Authorization-Lifetime AVP
10.9
8.10 Auth-Grace-Period AVP
8.11 Auth-Session-State AVP
8.12 Re-Auth-Request-Type AVP
8.13 Session-Timeout AVP
10.10
8.14 User-Name AVP
10.11
8.15 Termination-Cause AVP
10.12
8.16 Origin-State-Id AVP
10.13
8.17 Session-Binding AVP
10.14
8.18 Session-Server-Failover AVP
10.15
8.19 Multi-Round-Time-Out AVP
10.16
8.20 Class AVP
11.0
9.0 Accounting
11.1
9.1 Server Directed Model
11.2
9.2 Protocol Messages
11.3
9.3 Application document requirements
11.4

Calhoun et al. expires January 2002 [Page 4]

Internet-Draft July 2001

9.4 Fault Resilience
11.5
9.5 Accounting Records
11.6
9.6 Correlation of Accounting Records
12.0
9.7 Accounting Command-Codes
12.1
9.7.1 Accounting-Request
12.2
9.7.2 Accounting-Answer
13.0
9.8 Accounting AVPs
13.1
9.8.1 Accounting-Record-Type AVP
13.2
9.8.2 Accounting-Interim-Interval AVP
13.3
9.8.3 Accounting-Record-Number AVP
13.4
9.8.4 Accounting-Session-Id AVP
13.5
9.8.5 Accounting-Multi-Session-Id AVP
14.0
10.0 AVP Occurrence Table
14.1
10.1 Base Protocol Command AVP Table
14.2
10.2 Accounting AVP Table

Calhoun et al. expires December 2001 [Page 4]

Internet-Draft June 2001

15.0
11.0 IANA Considerations
15.1
11.1 AVP Header
15.1.1
11.1.1 AVP Code
15.1.2
11.1.2 AVP Flags
15.2
11.2 Diameter Header
15.2.1
11.2.1 Command Codes
15.2.2
11.2.2 Message Flags
15.3
11.3 Application Identifier Values
15.4
11.4 Result-Code AVP Values
15.5
11.5 Accounting-Record-Type AVP Values
15.6
11.6 Termination-Cause AVP Values
15.7
11.7 Redirect-Host-Usage AVP Values
15.8
11.8 Session-Server-Failover AVP Values
15.9
11.9 Session-Binding AVP Values
15.10
11.10 Diameter TCP/SCTP Port Numbers
16.0
11.11 Disconnect-Cause AVP Values
11.12 Auth-Request-Type AVP Values
11.13 Auth-Session-State AVP Values
11.14 Re-Auth-Request-Type AVP Values
12.0 Diameter protocol related configurable parameters
17.0
13.0 Security Considerations
18.0
14.0 References
19.0
15.0 Acknowledgements
20.0
16.0 Authors' Addresses
21.0
17.0 Full Copyright Statement
22.0
18.0 Expiration Date
Appendix A. Diameter Service Template

Calhoun et al. expires December 2001 January 2002 [Page 5]

Internet-Draft June July 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 December 2001 January 2002 [Page 6]

Internet-Draft June July 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.
- Relaying, proxying and 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 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 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 December 2001 January 2002 [Page 7]

Internet-Draft June July 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 Agent

Calhoun et al. expires December 2001 January 2002 [Page 8]

Internet-Draft June July 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 Node
A Diameter node is a host that implements the Diameter protocol,
and acts either as a Client, or as a Proxy, Redirector, Server or
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
See Diameter 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.

Calhoun et al. expires December 2001 January 2002 [Page 9]

Internet-Draft June July 2001

Proxy
In addition to forwarding requests and responses, proxies enforce
policies relating to resource usage and provisioning. This is
typically accomplished by tracking the state of 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.

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
understand the semantics of messages or non-routing AVPs, and are
capable of handling any Diameter 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. Since Re-directs do not sit in the
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 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 January 2002 [Page 10]

Internet-Draft June July 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 Diameter applications
are defined by companion documents: NASREQ [7], Mobile IP [10], CMS
Security [11]. These options are introduced in this document but
specified elsewhere. Additional Diameter applications MAY be defined
in the future (see Section 15.3). 11.3).

Diameter Clients MUST support the base protocol, which includes
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, MUST be referred to as "Diameter X Server"
where X is the application which it supports, and not a "Diameter
Server."

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

Calhoun et al. expires December 2001 January 2002 [Page 11]

Internet-Draft June July 2001

Diameter Proxies MUST suppport support the base protocol, which includes
accounting. in addition, they MUST fully support 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 referred to as "Diameter X Proxy"
where X is the application which it supports, and not a "Diameter
Proxy."

The CMS Diameter security application [11] contains two features:
1. A set of messages that allows a Diameter node to establish a
security association, which is used to secure AVPs within a
Diameter message, even though the message may traverse
intermediate Diameter agents. A set of AVPs are also defined to
sign and encrypt AVPs, as well as to transport certificates.
This feature MUST be supported by Diameter server and proxy
agents, SHOULD be supported by Diameter clients, and MAY be
supported by relay and redirector agents.
2. A set of messages, known as PDSR and PDSA, allows a Diameter
client to request that an agent establish a Diameter security
association with a server in a specific realm. This feature
MUST be supported by Diameter clients and Proxy agents, and MAY
be supported by Diameter servers, relay and redirector agents.

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 Diameter application. One AVP
that is included to reference a user's session is the Session-Id.

The initial request for authentication and/or authorization of a user
would include the Session-Id. The Session-Id is then used in all
subsequent messages to identify the user's session (see section 10.0 8.0
for more information). The communicating party may accept the
request, or reject it by returning 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
application employed.

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

Calhoun et al. expires December 2001 January 2002 [Page 12]

Internet-Draft June July 2001

The Diameter base protocol provides the Authorization-Lifetime AVP,
which MAY be used by 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 protocol is run on port TBD of
both TCP and SCTP.

Diameter clients MUST support either TCP or SCTP, while agents and
servers MUST support both. Future versions of this specification MAY
mandate that clients support 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. This behavior is handled
via the Tc timer, whose recommended value is 30 seconds.

When connecting to a peer, and either zero or more transports are
specified, SCTP SHOULD be tried first, followed by TCP. See section
2.6
5.2 for more information on peer discovery.

Diameter implementations SHOULD be able to interpret ICMP protocol
and port unreachable messages as explicit indications that the server
is not reachable, in addition to interpreting ECONNREFUSED (a reset
from the transport) and timed-out connection attempts.

2.1.1 SCTP Guidelines

The following are guidelines for Diameter implementations that
support SCTP:

1. For interoperability: All Diameter nodes MUST be prepared to
receive Diameter messages on any SCTP stream in the

Calhoun et al. expires December 2001 January 2002 [Page 13]

Internet-Draft June July 2001

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 MUST support IP Security [37], and MAY support TLS [38].
Diameter servers MUST support TLS, but the administrator MAY opt to
configure IPSec instead of using TLS. Operating the Diameter protocol
without any security mechanism is not 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

Defining a new AVP value is the best approach when a new application
needs to make use of an existing Diameter 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.

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 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,

Calhoun et al. expires December 2001 January 2002 [Page 14]

Internet-Draft June July 2001

it is highly recommended that a Grouped AVP be used (see Section
4.5).

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 application MUST NOT
be defined to have the 'M'andatory bit set.

2.3.3 Creating new Diameter Applications

Should a new application require Diameter support, but it cannot fit
within an existing application without requiring major changes to the
specification, it may be desirable to create a new Diameter
application. Major changes to an 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. application foo has a command that
requires one round trip, but new application bar has a command
that requires two round trips to complete).
- The method used to authenticate the user is drastically
different from any existing application, and the authentication
information cannot be carried within the AVPs defined in the
application.

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

New Diameter applications MUST define at least one Command Code, the
expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also
define new AVPs. If the Diameter application has any accounting
requirements, it MUST also specify the AVPs that are to be present in
the Diameter Accounting messages (see section 11.3). 9.3).

When possible, a new Diameter 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 application specification MUST have an IANA assigned
Application Identifier (see section 2.4).

2.3.4 Application authentication procedures

When possible, applications SHOULD be designed such that new

Calhoun et al. expires December 2001 January 2002 [Page 15]

Internet-Draft June July 2001

authentication methods MAY be added without requiring changes to the
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 Application Compliance

Application Identifiers are advertised during the capabilities
exchange phase (see section 6.0). 2.5). For a given application, there are
two different ways of advertising support. First, advertising support
of the application via the 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 application via the
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 application's specification.

An implementation MAY add arbitrary AVPs to any command defined in an
application, including vendor-specific AVPs. However, implementations
that add such AVPs with the Mandatory 'M' bit set are not compliant,
and are at fault if the peer rejects the request. If the sender of
such a message wishes to provide service, it MUST resend the message
with the offending AVPs removed.

2.5 Role of Application Identifiers

Each Diameter Agents

In addition to client and servers, application MUST have an IANA assigned Application
Identifier (see section 11.3). The base protocol does not require an
application Identifier since its support is mandatory. During the
capabilities exchange, Diameter protocol introduces
relays, redirectors, proxies and translation gateways, each nodes inform their peers of locally
supported applications. Furthermore, all Diameter messages contain an
application identifier, which is defined used in Section 1.3. These Diameter agents the message forwarding
process.

The following Application Identifier values are useful for
several reasons:
- They can distribute administration of systems to a configurable
grouping, including defined:

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

Relay and redirect agents MUST advertise the maintenance of security associations.
- They can be used for concentration Relay application
identifier, while all other Diameter nodes MUST advertise locally
supported applications. The receiver of requests from an number of
co-located or distributed NAS equipment sets to a set of like
user groups.
- They can do value-added processing to the requests or responses.
- They can be used for load balancing.
- A complex network will have multiple authentication sources,
they can sort requests and forward towards the correct target.

The Diameter protocol requires that agents maintain transaction
state, which is used for failover purposes. Transaction state implies
that upon forwarding a request, it's Hop-by-Hop identifier is saved,
the field is replaced with a locally unique identifier, which is Capabilities Exchange

Calhoun et al. expires December 2001 January 2002 [Page 16]

Internet-Draft June July 2001

restored to its original value when

message advertising Relay service MUST assume that the corresponding answer is
received. The request's state is released upon receipt of sender
supports all current and future applications.

Diameter relay and proxy agents are responsible for finding an
upstream server that supports the answer.
A stateless agent application of a particular
message. If none can be found, an error message is one that only maintains transaction state.

The Proxy-Info returned with the
Result-Code AVP allows stateless agents to add local state set to a DIAMETER_UNABLE_TO_DELIVER.

2.6 Peer Table

The Diameter request, with Peer Table is used in message forwarding, and referenced
by the guarantee that Domain Routing Table. A Peer Table entry contains the same state will be
present
following fields:
- Host identity. following the conventions described for the
DiameterIdentity derived AVP data format in section 4.4. This
MAY be resolved locally, or dynamically updated via the answer. However, Origin-
Host AVP of the protocol's failover procedures
require that agents maintain a copy of pending requests.

A stateful agent CER or CEA messages.
- Status. This is one that maintains session the state information, by
keeping track of all authorized active sessions. Each authorized
session is bound to a particular service, the peer entry, and its state is considered
active either until it is notified otherwise, or by expiration. Each
authorized session has a expiration, which is communicated by
Diameter servers via MUST match one
of the Authorized-Lifetime AVP.

Maintaining session state MAY be useful values listed in certain applications, such
as:
- Protocol translation (e.g. RADIUS <-> Diameter) section 5.6.
- Limiting resources authorized to Role. This field specifies whether a particular user peer is a primary,
secondary or alternate.
- Per user Static or transaction auditing

A Diameter agent MAY act in Dynamic. Specifies whether a stateful manner for some requests,
while be stateless for others. A Diameter implementation MAY act as
one type of agent for some requests, and as another type of agent for
others.

2.5.1 Relay Agents

Relay Agents peer entry was statically
configured, or dynamically discovered.
- Expiration time. Specifies the time which dynamically discovered
peer table entries are Diameter agents that accept requests and route
messages to other Diameter agents based on information found in be either refreshed, or expired.
- TLS Enabled. Specifies whether TLS is to be used when
communicating with the
messages peer.
- Additional security information, when needed (e.g. Destination-Realm). This keys,
certificates)

2.7 Realm-Based Routing Table

All Realm-Based routing decision is lookups are performed
using a list of supported domains, and known peers. This against what is
commonly known as the Diameter Domain Routing Table, as is defined further in Table (see section 5.1.7.

Relays MAY be used to aggregate requests from multiple Network Access
Servers (NASes) within a common geographical area (POP). The use of
Relays is advantageous since it eliminates 12.0). A
Domain Routing Table Entry contains the need for NASes to be
configured with following fields:
- Realm Name. This is the necessary security information they would
otherwise require to communicate with Diameter servers field that is typically used as a
primary key in other
realms. Likewise, this reduces the configuration load on Diameter
servers routing table lookups. Note that would otherwise be necessary when NASes are added,
changed some
implementations perform their lookups based on longest-match-
from-the-right on the realm rather than requiring an exact
match.
- Application Identifier. It is possible for a route entry to have
a different destination based on the Acct-Application-Id (for
accounting messages) or deleted.

Relays modify Diameter messages by inserting, and removing, routing
information, but do not modify any other portion Auth-Application-Id (for non-accounting
messages) of a the message.
Further, Relays inherent simplicity implies that they are stateless, 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

Calhoun et al. expires December 2001 January 2002 [Page 17]

Internet-Draft June July 2001

and therefore SHOULD NOT maintain session state, but MUST maintain
transaction state.

+------+ ---------> +------+ ---------> +------+
| |

message should be treated. The following actions are supported:
1. Request | | LOCAL - Diameter messages that resolve to a route entry
with the Local Action set to Local can be satisfied
locally, and do not need to be routed to another server.
2. Request | |
| NAS | | DRL | | HMS |
| | 4. Answer | | 3. Answer | |
+------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com
Figure 1: Relaying of RELAY - All Diameter messages

The example provided in Figure 1 depicts a request issued from NAS,
which is an access device, for the user bob@abc.com. Prior that fall within this
category MUST be routed to issuing
the request, NAS performs a next hop server, without
modifying any non-routing AVPs. See section 6.1.8 for
relaying guidelines
3. PROXY - All Diameter route lookup, using "abc.com" as
the key, and determines messages that the message is to fall within this
category MUST be relayed routed to DRL,
which is a Diameter Relay. DRL performs the same route lookup as NAS,
and relays next hop server. The local
server MAY apply its local policies to the message by
including new AVPs to HMS, which is abc.com's Home Diameter
Server. HMS identifies that the request can be locally supported (via
the realm), processes the authentication and/or authorization
request, and replies with an answer, which is routed back message prior to NAS
using Diameter routing AVPs.

Since Relays do not perform any application level processing, they
provide relaying services routing. See
section 6.1.8 for all relaying guidelines.
4. REDIRECT - Diameter applications, and
therefore messages that fall within this
category MUST advertise have the Relay Application Identifier.

2.5.2 Proxy Agents

Similarly to Relays, Proxy agents route Diameter messages using identity of the home Diameter Routing Table. However, they differ since they modify
messages
server(s) appended, and returned to implement policy enforcement. This requires that proxies
maintain the state sender of their downstream peers (e.g. access devices) to
enforce resource usage, provide admission control, and provisioning.

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

Proxies MAY be used in call control centers
message. See section 6.1.7 for redirect guidelines.
- Server Identifier. One or access ISPs that
provide outsourced connections, they can monitor more servers the number and types
of ports in use, and make allocation and admission decisions
according to their configuration.

Proxies that wish message is to limit resources MUST be stateful, and all
Proxies MUST maintain transaction state.

Calhoun et al. expires December 2001 [Page 18]

Internet-Draft June 2001

Proxy agents
routed to. These servers MUST NOT allow CMS security to also be established between
two peers if it expects to modify ANY non-routing AVP present in messages
exchanged between the 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 forwarded. Peer
table. When a request is received by a Diameter redirector, a
special answer the Local Action is created, which includes set to RELAY or PROXY, this
field contains the identity of the
Diameter server(s) the originator message must be
routed to. When the Local Action field is set to REDIRECT, this
field contains the identity of one or more servers the request message
should contact
directly.

Redirectors are useful in scenarios where the Diameter routing
configuration needs to be centralized. An example is redirected to.
- Static or Dynamic. Specifies whether a redirector route entry was
statically configured, or dynamically discovered.
- Expiration time. Specifies the time which dynamically discovered
a route table entry expire.

It is important to note that provides services Diameter agents MUST support at least
one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents
do not need to support all members modes of a consortium, but does not
wish operation in order to be burdened conform
with relaying all messages between domains. This
scenario is advantageous since it does not require that the
consortium provide 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.

The routing updates to its members when changes are
made to table MAY include a member's infrastructure.

Since redirectors do not relay messages, and only return an answer
with the information necessary default entry which MUST be used for Diameter agents to communicate
directly, they do not modify messages. Since redirectors do not
receive answer messages, they cannot maintain session state.
Further, since redirectors never relay requests, they are
any requests not
required to maintain transaction state. matching any of the other entries. The example provided in Figure 2 depicts routing table
MAY consist of only such an entry.

When a request issued from is routed, the
access device, NAS, for target server MUST have advertised the user bob@abc.com. The message is
forwarded by
Application Identifier (see section 2.5) for the NAS to its relay, DRL, which does not given message, or
have advertised itself as a routing
entry in its relay or proxy agent.

2.8 Role of Diameter Routing Table for abc.com. DRL has a default
route configured to DRD, which is a redirector that returns a
redirect notification Agents

In addition to DLR, as well as HMS' contact information.
Upon receipt of the redirect notification, DRL establishes a
transport connection with HMS, if one doesn't already exist, client and
forwards servers, the request to it. Diameter protocol introduces

Calhoun et al. expires December 2001 January 2002 [Page 19] 18]

Internet-Draft June July 2001

+------+
| |
| 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

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

relays, redirectors, proxies and
therefore MUST advertise the 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 gateways, each of which
is defined in Section 1.3. These Diameter agents are likely to be used as aggregation servers to communicate
with a Diameter infrastructure, while allowing useful for the embedded
several reasons:
- They can distribute administration of systems to be migrated at a slower pace.

Given that the Diameter protocol introduces configurable
grouping, including the concept maintenance of long-lived
authorized sessions, translation agents MUST security associations.
- They can be stateful and MUST
maintain transaction state.

Translation used for concentration of messages can only occur if the agent recognizes the
application requests from an number of a particular request, and therefore MUST only
advertise their locally supported applications.

2.6 Diameter Agent Discovery

Calhoun et al. expires December 2001 [Page 20]

Internet-Draft June 2001

Allowing the requests or responses.
- They can be used for dynamic Diameter agent discovery load balancing.
- A complex network will make it possible
for simpler have multiple authentication sources,
they can sort requests and more robust deployment of AAA services. In order to
promote interoperable implementations of Diameter agent discovery, forward towards the following mechanisms are described. These are based on existing
IETF standards.

There are two cases where Diameter agent discovery may be performed. correct target.

The first is when a Diameter client needs to discover a first-hop Diameter agent. The second case protocol requires that agents maintain transaction
state, which is when a Diameter agent needs to
discover another agent - used for further handling of failover purposes. Transaction state implies
that upon forwarding a Diameter
operation. In both cases, request, it's Hop-by-Hop identifier is saved,
the following 'search order' field is
recommended:

1. The Diameter implementation consults its list of static
(manual) configured Diameter agent locations. These will be
used if they exist and respond.

2. The Diameter implementation uses SLPv2 [28] replaced with a locally unique identifier, which is
restored to discover
Diameter services. its original value when the corresponding answer is
received. The Diameter service template [32] request's state is
included in Appendix A. It released upon receipt of the answer.
A stateless agent is recommended one that SLPv2 security
be deployed (this requires distributing keys to SLPv2 agents.)
This is discussed further in Appendix A.

SLPv2 will allow Diameter implementations to discover the
location of Diameter only maintains transaction state.

The Proxy-Info AVP allows stateless agents in the to add local site, as well as their
characteristics. state to a
Diameter agents request, with specific capabilities
(say support for the Mobile IP application) 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 a
particular domain. The Diameter implementation has to know in
advance which domain to look for protocol's failover procedures
require that agents maintain a Diameter copy of pending requests.

A stateful agent in. This
could be deduced, for example, from the 'realm' in a NAI is one that a
Diameter implementation needed maintains session state information, by
keeping track of all authorized active sessions. Each authorized
session is bound to perform a Diameter operation
on.

3.1 If the destination address particular service, and its state is considered
active either until it is notified otherwise, or by expiration. Each
authorized session has a numeric IP address, the
requestor contacts the peer at the given address and expiration, which is communicated by
Diameter servers via the
port number specified Authorized-Lifetime AVP.

Maintaining session state MAY be useful in the SRV record or, if not
specified, the default port (TBD).

3.2 The results of the query certain applications, such
as:
- Protocol translation (e.g. RADIUS <-> Diameter)
- Limiting resources authorized to a particular user
- Per user or queries transaction auditing

A Diameter agent MAY act in a stateful manner for some requests,
while be stateless for others. A Diameter implementation MAY act as
one type of agent for some requests, and as another type of agent for
others.

2.8.1 Relay Agents

Relay Agents are merged Diameter agents that accept requests and ordered route

Calhoun et al. expires January 2002 [Page 19]

Internet-Draft July 2001

messages to other Diameter agents based on priority. Then, the searching technique outlined information found in
[46] the
messages (e.g. Destination-Realm). This routing decision is performed
using a list of supported domains, and known peers. This is known as
the Diameter Routing Table, as is defined further in section 2.7.

Relays MAY be used to select servers in order. aggregate requests from multiple Network Access
Servers (NASes) within a common geographical area (POP). The requestor
attempts to contact each peer in use of
Relays is advantageous since it eliminates the order listed, at need for NASes to be
configured with the
port number specified necessary security information they would
otherwise require to communicate with Diameter servers in other
realms. Likewise, this reduces the SRV record. If none of the configuration load on Diameter
servers can that would otherwise be contacted, the requestor gives up. If there

Calhoun et al. expires December 2001 [Page 21]

Internet-Draft June 2001

are no SRV records, DNS address records necessary when NASes are used, as
described below.

3.3 If there 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 no SRV records, the requestor queries the DNS
server for address records stateless,
and therefore SHOULD NOT maintain session state, but MUST maintain
transaction state.

+------+ ---------> +------+ ---------> +------+
| | 1. Request | | 2. Request | |
| NAS | | DRL | | HMS |
| | 4. Answer | | 3. Answer | |
+------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com
Figure 1: Relaying of Diameter messages

The example provided in Figure 1 depicts a request issued from NAS,
which is an access device, for the destination address
'_diameter._sctp'.domain or '_diameter._tcp'.domain. Address
records include A RR's, AAAA RR's, A6 RR's or other similar
records, chosen according user bob@abc.com. Prior to issuing
the requestor's network
protocol capabilities.

If request, NAS performs a Diameter route lookup, using "abc.com" as
the DNS server returns no address records, key, and determines that the requestor
gives up. If there are address records, message is to be relayed to DRL,
which is a Diameter Relay. DRL performs the same rules route lookup as in
step 3.2 apply.

Requestors MUST NOT cache query results except according to NAS,
and relays the
rules in [47]. Diameter allows AAA peers message to protect the
integrity and privacy of communication as well as to perform
end-point authentication. Still, it HMS, which is prudent abc.com's Home Diameter
Server. HMS identifies that the request can be locally supported (via
the realm), processes the authentication and/or authorization
request, and replies with an answer, which is routed back to employ DNS
Security as a precaution when NAS
using DNS SRV RRs to look up the
location of a Diameter agent. [34, 35, 36]

3.0 Diameter Header

A summary of the routing AVPs.

Since Relays do not perform any application level processing, they
provide relaying services for all Diameter header format is shown below. The fields
are transmitted in network byte order.

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

Version
This Version field applications, and
therefore MUST be set to 1 advertise the Relay Application Identifier.

2.8.2 Proxy Agents

Similarly to indicate Relays, Proxy agents route Diameter Version
1. messages using the
Diameter Routing Table. However, they differ since they modify

Calhoun et al. expires December 2001 January 2002 [Page 22] 20]

Internet-Draft June July 2001

Message Length
The Message Length field is two octets and indicates

messages to implement policy enforcement. This requires that proxies
maintain the length state of
the Diameter message including the header fields.

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

R(equest) - If set, the message their downstream peers (e.g. access devices) to
enforce resource usage, provide admission control, and provisioning.

It is important to note that although proxies MAY provide a request. If cleared, the
message is an answer.
P(roxiable) - If set, value-add
function for NASes, they do not allow access devices to use the message
Diameter CMS Security application, since modifying messages breaks
authentication.

Proxies MAY be proxied. If cleared, used in call control centers or access ISPs that
provide outsourced connections, they can monitor the message number and types
of ports in use, and make allocation and admission decisions
according to their configuration.

Proxies that wish to limit resources MUST be locally processed.
r(eserved) - this flag bit is reserved for future use, stateful, and all
Proxies MUST maintain transaction state.

Proxy agents MUST NOT allow CMS security to be set established between
two peers if it expects to zero.

Command-Code
The Command-Code field is three octets, and is used modify ANY non-routing AVP in order to
communicate messages
exchanged between the command associated with peers. See [11] for more information.

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

2.8.3 Redirector Agents

Redirector agents provide Realm to Server address space resolution, and use
the Diameter routing table to determine where a given request should
be forwarded. When a request is managed received by IANA (see section 15.2).

Vendor-ID
In a Diameter redirector, a
special answer is created, which includes the event that identity of the Command-Code field contains a vendor
specific command, the four octet Vendor-ID field contains
Diameter server(s) the IANA
assigned "SMI Network Management Private Enterprise Codes" [2]
value. If originator of the Command-Code field contains an IETF standard
Command, request should contact
directly.

Redirectors are useful in scenarios where the Vendor-ID field MUST be set to zero (0). Any vendor
wishing Diameter routing
configuration needs to implement be centralized. An example is a vendor-specific Diameter command MUST use
their own Vendor-ID along with their privately managed Command-
Code address space, guaranteeing redirector
that they will provides services to all members of a consortium, but does not collide with
any other vendor's vendor-specific command, nor
wish to be burdened with future IETF
applications.

Hop-by-Hop Identifier
The Hop-by-Hop Identifier field relaying all messages between domains. This
scenario is four octets, and aids in
matching requests and replies. The sender MUST ensure advantageous since it does not require that the
Hop-by-Hop identifier in
consortium provide routing updates to its members when changes are
made to a request is locally unique (to the
sender) at any given time, member's infrastructure.

Since redirectors do not relay messages, and MAY attempt to ensure that the
number is unique across reboots. The sender of only return an Answer message
MUST ensure that the Hop-by-Hop Identifier field contains the same
value that was found in the corresponding request. The Hop-by-Hop
identifier is normally a monotonically increasing number, whose
start value was randomly generated. An answer message that is
received
with an unknown Hop-by-Hop Identifier MUST be discarded.

End-to-End Identifier
Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is
used information necessary for Diameter agents to detect duplicate messages, and communicate
directly, they do not modify messages. Since redirectors do not
receive answer messages, they cannot maintain session state.
Further, since redirectors never relay agents MUST NOT requests, they are not

Calhoun et al. expires December 2001 January 2002 [Page 23] 21]

Internet-Draft June July 2001

modify this field.

required to maintain transaction state.

The sender of example provided in Figure 2 depicts a request or answer issued from the
access device, NAS, for the user bob@abc.com. The message MUST
insert is
forwarded by the NAS to its relay, DRL, which does not have a locally unique value routing
entry in this field. The combination of
the Origin-Host AVP and this field is used its Diameter Routing Table for abc.com. DRL has a default
route configured to detect duplicates.
An Answer message DRD, which is received with a previously seen End-
to-End Identifier, and is to be locally consumed (see Section 5.2)
SHOULD be silently discarded.

AVPs
AVPs are redirector that returns a method of encapsulating information relevant
redirect notification to DRL, as well as HMS' contact information.
Upon receipt of the
Diameter message. See section 4. for more information on AVPs.

3.1 Command Codes

Each command Request/Answer pair is assigned redirect notification, DRL establishes a command code,
transport connection with HMS, if one doesn't already exist, and
forwards the
sub-type (e.g. request or answer) is identified via the 'R' bit in
the Command Flags field of the Diameter header.

Every Diameter message MUST contain a command code in its header's
Command-Code field, which is used to determine the action that is to
be taken for a particular message. The following Command Codes are
defined in the Diameter base protocol:

Command-Name Abbrev. Code Reference
--------------------------------------------------------
Abort-Session-Request ASR 274 10.5.1
Abort-Session-Answer ASA 274 10.5.2
Accounting-Request ACR 271 12.1
Accounting-Answer ACA 271 12.2
Capabilities-Exchange- CER 257 6.2 it.

+------+
| |
| DRD |
| |
+------+
^ |
2. Request
Capabilities-Exchange- CEA 257 6.3
Answer
Device-Watchdog-Request DWR 280 7.1
Device-Watchdog-Answer DWA 280 7.2
Message-Reject-Answer MRA 282 9.2
Re-Auth-Request RAR 258 10.3.1
Re-Auth-Answer RAA 258 10.3.2
Session-Termination- STR 275 10.4.1 | | 3. Redirection
| | Notification
| v
+------+ ---------> +------+ ---------> +------+
| | 1. Request
Session-Termination- STA 275 10.4.2 | | 4. Request | |
| NAS | | DRL | | HMS |
| | 6. Answer

3.2 Command Code ABNF specification

Every Command Code defined MUST include | | 5. Answer | |
+------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com
Figure 2: Redirecting a corresponding ABNF
specification, which Diameter Message

Since Redirectors do not perform any application level processing,
they provide relaying services for all Diameter applications, and
therefore MUST advertise the Relay Application Identifier.

2.8.4 Translation Agents

A Translation Agent is a device that provides translation between two
protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation
agents are likely to be used as aggregation servers to define communicate
with a Diameter infrastructure, while allowing for the AVPs embedded
systems to be migrated at a slower pace.

Given that the Diameter protocol introduces the concept of long-lived
authorized sessions, translation agents MUST or MAY be stateful and MUST
maintain transaction state.

Translation of messages can only occur if the agent recognizes the
application of a particular request, and therefore MUST only

Calhoun et al. expires December 2001 January 2002 [Page 24] 22]

Internet-Draft June July 2001

present. The following format is used in the definition:

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

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

command-name = diameter-name
; The command-name has

advertise their locally supported applications.

+------+ ---------> +------+ ---------> +------+
| | RADIUS Request | | Diameter Request | |
| NAS | | TLA | | HMS |
| | RADIUS Answer | | Diameter Answer | |
+------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com
Figure 3: Translation of RADIUS to be Command name,
; defined in Diameter

3.0 Diameter Header

A summary of the base or extended Diameter
; specifications.

diameter-message = header [ *fixed] [ *required] [ *optional]
[ *fixed] header = "<Diameter-Header:" command-id [r-bit] [p-bit] ">"

command-id = 1*DIGIT
; format is shown below. The Command Code assigned fields
are transmitted in network byte order.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R P E 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 1 to indicate Diameter Version
1.

Message Length
The Message Length field is three octets and indicates the command

r-bit = ", REQ"
; If present, length
of the 'R' bit in Diameter message including the header fields.

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

R(equest) - If set, indicating that the message
; is a request, as opposed to an answer.

p-bit = ", PXY"
; request. If present, the 'P' bit in cleared, the Command
; Flags
message is an answer.
P(roxiable) - If set, indication that the message
; is proxiable.

fixed = [qual] "<" avp-spec ">"
; Defines the fixed position of an AVP

required = [qual] "{" avp-spec "}"
; The AVP MUST MAY be present

optional = [qual] "[" avp-name "]"
; The avp-name in proxied. If cleared,
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 message MUST be present.
;
; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above).
; These braces cannot be used to express locally processed.

Calhoun et al. expires December 2001 January 2002 [Page 25] 23]

Internet-Draft June July 2001

; optional fixed rules (such as an optional
; ICV at

E(rror) - If set, the end.) To do this, message contains a protocol error,
and the convention
; is '0*1fixed'.

min = 1*DIGIT
; The minimum number of times message will not conform to the element may
; be present. The default value is zero.

max = 1*DIGIT
; The maximum number of times ABNF
described for this command. Messages with the element may
; be present. The default value
'E' bit set is infinity.

avp-spec = diameter-name
; The avp-spec has commonly referred to be as an AVP Name, defined
; error
message. This bit MUST NOT be set in the base or extended Diameter
; specifications.

avp-name = avp-spec | "AVP"
; The string "AVP" stands request
messages. See section 7.2.
r(eserved) - this flag bit is reserved for *any* arbitrary
; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in
; the command code definition. future use, and
MUST be set to zero.

Command-Code
The following Command-Code field is a definition of a fictitious command code:

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

3.3 Diameter Command Naming Conventions

The following conventions are required for the naming of Diameter
messages. Diameter commands typically start with an object name, three octets, and
end is used in order to
communicate the command associated with either the Request or Answer verb. message. The Request/Answer message pair 24-bit
address space is used when a Diameter node requests
that some action be performed managed by a peer (e.g. authorize a user,
terminate a session). The corresponding answer MUST contain either a
positive or negative result code, informing IANA (see section 11.2).

Vendor-ID
In the requester whether event that the
request was successful or not. Other information MAY also be returned
in Command-Code field contains a vendor
specific command, the Answer message.

Request and Answer messages share four octet Vendor-ID field contains the same command code, and IANA
assigned "SMI Network Management Private Enterprise Codes" [2]
value. If the
R(equest) bit in Command-Code field contains an IETF standard
Command, the Diameter header is used Vendor-ID field MUST be set to identify whether zero (0). Any vendor
wishing to implement a
message is the request or answer.

Calhoun et al. expires December 2001 [Page 26]

Internet-Draft June 2001

4.0 Diameter AVPs vendor-specific Diameter AVPs carry specific authentication, accounting command MUST use
their own Vendor-ID along with their privately managed Command-
Code address space, guaranteeing that they will not collide with
any other vendor's vendor-specific command, nor with future IETF
applications.

Hop-by-Hop Identifier
The Hop-by-Hop Identifier field is four octets, and
authorization information, security information as well as
configuration details for aids in
matching requests and replies. The sender MUST ensure that the
Hop-by-Hop identifier in a request is locally unique (to the
sender) at any given time, and reply.

Some AVPs MAY be listed more than once. attempt to ensure that the
number is unique across reboots. The effect sender of such an AVP is
specific, and is specified Answer message
MUST ensure that the Hop-by-Hop Identifier field contains the same
value that was found in each case by the AVP description.

Each AVP of type OctetString corresponding request. The Hop-by-Hop
identifier is normally a monotonically increasing number, whose
start value was randomly generated. An answer message that is
received with an unknown Hop-by-Hop Identifier MUST be padded discarded.

End-to-End Identifier
The End-to-End Identifier is used to align on a 32 bit
boundary, while other AVP types align naturally. NULL bytes detect duplicate messages.
Upon reboot, the high order 12 bits are added initiated to contain the end
low order 12 bits of current time, while the AVP Data field till a word boundary low order 20 bits is reached. The
length
set to a random value. Senders of request or answer messages MUST
insert a unique identifier on each message, by incrementing the padding is not reflected in the AVP Length field.

4.1 AVP Header

The fields in the AVP header
identifier by one (1). The End-to-End Identifier MUST NOT be sent in network byte order.
modified by relay agents. The
format combination of the header is:

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

AVP Code
The AVP Code, combined with the Vendor-Id field, identifies the
attribute uniquely. The first 256 AVP numbers are reserved for
backward compatibility with RADIUS Origin-Host and
this field is used to detect duplicates. Duplicate answer messages
that are to be interpreted as
per NASREQ [7]. AVP numbers 256 and above are used for Diameter,
which are allocated by IANA locally consumed (see section 15.1).

AVP Flags
The AVP Flags field informs the receiver how each attribute must
be handled. The 'r' (reserved) bits are unused and SHOULD be set
to 0. Note that subsequent Diameter applications MAY define
additional bits within the AVP Header, and an unrecognized bit Section 6.2) SHOULD be considered an error. 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

Calhoun et al. expires December 2001 January 2002 [Page 27] 24]

Internet-Draft June July 2001

set is received by a Diameter node,

silently discarded.

AVPs
AVPs are a method of encapsulating information relevant to the message MUST be rejected.
Diameter Relay and Redirector agents MUST NOT reject messages with
unrecognized message. See section 4. for more information on AVPs.

A Diameter node that sets the 'M' bit in an AVP that

3.1 Command Codes

Each command Request/Answer pair is not
defined in assigned a given message's ABNF is at fault if command code, and the message
sub-type (e.g. request or answer) is
rejected. In order to provide service to identified via the user, 'R' bit in
the node at
fault MUST re-issue a request either without Command Flags field of the AVP, or without
setting its 'M' bit.

A Diameter node that rejects a header.

Every Diameter message due MUST contain a command code in its header's
Command-Code field, which is used to an unrecognized AVP
with the 'M' bit set, and determine the AVP in question action that is to
be taken for a particular message. The following Command Codes are
defined in the
message's Diameter base protocol:

Command-Name Abbrev. Code Reference
--------------------------------------------------------
Abort-Session-Request ASR 274 8.5.1
Abort-Session-Answer ASA 274 8.5.2
Accounting-Request ACR 271 9.7.1
Accounting-Answer ACA 271 9.7.2
Capabilities-Exchange- CER 257 5.3.1
Request
Capabilities-Exchange- CEA 257 5.3.2
Answer
Device-Watchdog-Request DWR 280 5.5.1
Device-Watchdog-Answer DWA 280 5.5.2
Disconnect-Peer-Request DPR 282 5.4.1
Disconnect-Peer-Answer DPA 282 5.4.2
Re-Auth-Request RAR 258 8.3.1
Re-Auth-Answer RAA 258 8.3.2
Session-Termination- STR 275 8.4.1
Request
Session-Termination- STA 275 8.4.2
Answer

3.2 Command Code ABNF specification

Every Command Code defined MUST include a corresponding ABNF
specification, which is at fault. In most cases the initiator of the
failing request will not provide service used to define 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 MUST or MAY simply ignore the AVP. be
present. The 'V' bit, known as the Vendor-Specific bit, indicates whether
the optional Vendor-ID field following format is present used in the AVP header. When
set definition:

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

Calhoun et al. expires January 2002 [Page 25]

Internet-Draft July 2001

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

command-name = diameter-name
; The command-name has to be Command name,
; defined in the AVP base or extended Diameter
; specifications.

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

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

command-id = 1*DIGIT
; The Command Code belongs assigned to the specific vendor code address
space.

Unless otherwise noted, AVPs will have command

r-bit = ", REQ"
; If present, the following default AVP
Flags field settings:
The 'M' bit MUST be set. The 'V' 'R' 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, in the Vendor-ID field (if present) and Command
; Flags is set, indicating that the AVP data. If a message
; is
received with a request, as opposed to an invalid attribute length, answer.

p-bit = ", PXY"
; If present, the message SHOULD be
rejected.

4.2 Optional Header Elements

The AVP Header contains one optional field. This field is only
present if 'P' bit in the respective bit-flag Command
; Flags is enabled.

Vendor-ID
The Vendor-ID field set, indication that the message
; is present if proxiable.

e-bit = ", ERR"
; If present, the 'V' 'E' bit is set in the AVP Command
; Flags field. The optional four octet Vendor-ID field is set, indication that the answer
; message contains a Result-Code AVP in
; the
IANA assigned "SMI Network Management Private Enterprise Codes"
[2] value, encoded "protocol error" class.

fixed = [qual] "<" avp-spec ">"
; Defines the fixed position of an AVP

required = [qual] "{" avp-spec "}"
; The AVP MUST be present

optional = [qual] "[" avp-name "]"
; The avp-name in network byte order. Any vendor wishing the 'optional' rule cannot
; evaluate to
implement any AVP Name which is included
; in a vendor-specific Diameter 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 use their own
Vendor-ID along with their privately managed AVP address space, be present.
;

Calhoun et al. expires December 2001 January 2002 [Page 28] 26]

Internet-Draft June July 2001

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

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

min = 1*DIGIT
; The minimum number of times the vendor ID
field implies that the AVP in question element may
; be present. The default value is not vendor specific,
implementations SHOULD not use zero.

max = 1*DIGIT
; The maximum number of times the zero (0) vendor ID.

4.3 AVP Base Data Format element may
; be present. The Data field default value is zero or more octets and contains information
specific infinity.

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

avp-name = avp-spec | "AVP"
; The format and length of string "AVP" stands for *any* arbitrary
; AVP Name, which does not conflict with the Data field is
determined by
; required or fixed position AVPs defined in
; the AVP Code and AVP Length fields. command code definition.

The format following is a definition of a fictitious command code:

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

3.3 Diameter Command Naming Conventions

The following conventions are required for the
Data field MUST be one naming of Diameter
messages. Diameter commands typically start with an object name, and
end with either the following base data types Request or Answer verb.

The Request/Answer message pair is used when a data
type derived from the base data types. In the event Diameter node requests
that some action be performed by a new AVP
Base Data Format is needed, peer (e.g. authorize a new version of this RFC must be
created.

OctetString user,
terminate a session). The data contains arbitrary data of variable length. Unless
otherwise noted, the AVP Length field corresponding answer MUST be set to at least 8
(12 if contain either a
positive or negative result code, informing the 'V' bit is enabled). 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

Calhoun et al. expires January 2002 [Page 27]

Internet-Draft July 2001

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 Values of this type that
do not OctetString MUST be padded to align on a 32-bit boundary MUST have the necessary
padding.

Integer32 32 bit signed value, in network byte order. The
boundary, while other AVP Length
field MUST be set types align naturally. NULL bytes are added
to 12 (16 if the 'V' bit is enabled).

Integer64
64 bit signed value, in network byte order. The end of the AVP Length Data field MUST be set to 16 (20 if till a word boundary is reached. The
length of the 'V' bit padding is enabled).

Unsigned32
32 bit unsigned value, not reflected in network byte order. The the AVP Length
field field.

4.1 AVP Header

The fields in the AVP header MUST be set to 12 (16 if the 'V' bit is enabled).

Unsigned64
64 bit unsigned value, sent 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
format of single precision as
described by [30]. the header is:

AVP Code
The 32 bit value is transmitted in network
byte order. AVP Code, combined with the Vendor-Id field, identifies the
attribute uniquely. The first 256 AVP Length 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 11.1).

AVP Flags
The AVP Flags field MUST informs the receiver how each attribute must
be handled. The 'r' (reserved) bits are unused and SHOULD be set
to 12 (16 if 0. Note that subsequent Diameter applications MAY define
additional bits within the

Float64 AVP Header, and an unrecognized bit

Calhoun et al. expires December 2001 January 2002 [Page 29] 28]

Internet-Draft June July 2001

This represents floating point values of double precision as
described by [30].

SHOULD be considered an error. The 64 'P' bit value is transmitted defined in network
byte order. [11].

The AVP Length field MUST be set to 16 (20 if 'M' Bit, known as the

Float128
This represents floating point values Mandatory bit, indicates whether support
of quadruple precision as
described by [30]. The 128 bit value the AVP is transmitted in network
byte order. The required. If an unrecognized AVP Length field MUST be set to 24 (28 if with the

Grouped
The Data field 'M' bit
set is specified as received by a sequence of Diameter node, the message MUST be rejected.
Diameter Relay and Redirector agents MUST NOT reject messages with
unrecognized AVPs. Each of
these AVPs follows - in

A Diameter node that sets the order 'M' bit in which they are specified -
including their headers and padding. The an AVP Length field that is
set to 8 (12 not
defined in a given message's ABNF is at fault if the 'V' bit message is enabled) plus the total length
of all included AVPs, including their headers and padding.

4.4 Derived AVP Data Formats
rejected. In addition order to provide service to the AVP Base Data Formats, applications may define
data formats derived from the AVP Base Data Formats. New AVP Derived
Data Formats MUST be registered with IANA.

An application that uses AVP Derived Data Formats other than those
defined in user, the base protocol node at
fault MUST have re-issue a section "AVP Derived Data
Formats" that includes each of these formats. In that section, each
format is request either defined without the AVP, or listed with without
setting its 'M' bit.

A Diameter node that rejects a reference message due to an unrecognized AVP
with the RFC that
defines this format. If 'M' bit set, and the AVP Derived Data Format in question is defined, it
SHOULD use a format similar to defined in the format definitions below.

The below AVP Derived DATA Formats are commonly used by applications.

IPAddress
The IPAddress format
message's ABNF is derived from at fault. In most cases the OctetString AVP Base
Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) [16]
address, most significant octet first. The format initiator of the
address (IPv4 or IPv6)
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 determined by not
supported MAY simply ignore the length. If AVP.

The 'V' bit, known as the
attribute value Vendor-Specific bit, indicates whether
the optional Vendor-ID field is an IPv4 address, present in the AVP Length 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 12 (16 if set. The 'V' bit MUST NOT be set.

AVP Length
The AVP Length field is enabled), otherwise three octets, and indicates the length of
this AVP Length including the AVP Code, AVP Length, AVP Flags, Reserved,
the Vendor-ID field MUST (if present) and the AVP data. If a message is
received with an invalid attribute length, the message SHOULD be set to 24 (28
rejected.

4.2 Optional Header Elements

The AVP Header contains one optional field. This field is only
present if the 'V' bit respective bit-flag is enabled) for IPv6
addresses.

Time enabled.

Vendor-ID
The Time format Vendor-ID field is derived from present if the Unsigned32 AVP Base Format.
This is 32 'V' bit unsigned value containing is set in the AVP
Flags field. The optional four most
significant octets returned from NTP [18], in network byte
order. octet Vendor-ID field contains the

Calhoun et al. expires December 2001 January 2002 [Page 30] 29]

Internet-Draft June July 2001

This represent the number of seconds since 0h on 1 January 1900

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 respect 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 Coordinated Universal Time (UTC).

On 6h 28m 16s UTC, 7 February 2036 IETF adopted AVP
values, as managed by the time value will
overflow. NTP [18] describes a procedure to extend IANA. Since the time to
2104.

UTF8String
The UTF8String format absence of the vendor ID
field implies that the AVP in question is derived from not vendor specific,
implementations SHOULD not use the OctetString zero (0) vendor ID.

4.3 AVP Base
Format. This Data Format

The Data field is a human readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString
using zero or more octets and contains information
specific to the UTF-8 [29] transformation Attribute. The format described in RFC
2279.

Since additional code points are added and length of the Data field is
determined by amendments to the
10646 standard from time to time, implementations AVP Code and AVP Length fields. The format of the
Data field MUST be
prepared to encounter any code point from 0x00000001 to
0x7fffffff. Byte sequences that do not correspond to the valid
UTF-8 encoding one of a code point the following base data types or are outside this range are
prohibited. Note that since a code point of 0x00000000 is
prohibited, no octet will contain data
type derived from the base data types. In the event that a value new AVP
Base Data Format is needed, a new version of 0x00. this RFC must be
created.

OctetString
The use data contains arbitrary data of control codes SHOULD variable length. Unless
otherwise noted, the AVP Length field MUST be avoided. When it is
necessary set to represent a newline, at least 8
(12 if the control code sequence CR
LF SHOULD be used.

The use 'V' bit is enabled). AVP Values of leading or trailing white space SHOULD be avoided.

For code points this type that
do not directly supported by user interface
hardware or software, an alternative means of entry and
display, such as hexadecimal, MAY be provided.

For information encoded in 7-bit US-ASCII, align on a 32-bit boundary MUST have the UTF-8 encoding
is identical necessary
padding.

Integer32
32 bit signed value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the US-ASCII encoding.

UTF-8 may require multiple bytes 'V' bit is enabled).

Integer64
64 bit signed value, in network byte order. The AVP Length
field MUST be set to represent a single
character / code point; thus 16 (20 if the length of a UTF8String 'V' bit is enabled).

Unsigned32
32 bit unsigned value, in
octets may network byte order. The AVP Length
field MUST be different from the number of characters encoded.

Note that set to 12 (16 if the size of an UTF8String 'V' bit is measured enabled).

Unsigned64
64 bit unsigned value, in octets, not
characters. network byte order. The UTF8String AVP Length
field MUST not contain any octets with a value of
zero.

DiameterIdentity
The DiameterIdentity format is derived from the OctetString AVP
Base Format. It uses the UTF-8 encoding and has be set to 16 (20 if the same 'V' bit is enabled).

Float32
This represents floating point values of single precision as

Calhoun et al. expires December 2001 January 2002 [Page 31] 30]

Internet-Draft June July 2001

requirements as the UTF8String. In addition, it must follow
the Uniform Resource Identifiers (URI) syntax [29] rules
specified below:

Diameter-Identity = [scheme-name] fqdn [ port ]
[ transport ]

scheme-name = "aaa://" aaa-protocol "/"
; If absent, the default BASE for relative URI references
;

described by [30]. The 32 bit value is aaa://diameter/

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

fqdn = Fully Qualified Host Name

port = ":" 1*DIGIT
; One of the ports used transmitted in network
byte order. The AVP Length field MUST be set to listen for incoming connections.
; If absent, 12 (16 if the default Diameter port (TBD) is assumed.

transport = ";transport=" ( "tcp" | "sctp" | "udp")
; One

Float64
This represents floating point values of the transports used to listen for incoming
; connections. If absent, the default SCTP [26] protocol double precision as
described by [30]. The 64 bit value is
; assumed. UDP transmitted in network
byte order. The AVP Length field MUST NOT be used when set to 16 (20 if the aaa-protocol field
;

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 diameter. 24 (28 if the

Grouped
The following are examples of valid Diameter host identities:

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

The first two forms are relative URI references, against the
default base of aaa://diameter/.

Since multiple Diameter processes on a single host cannot
listen for incoming connections on the same port on Data field is specified as a given
protocol, sequence of AVPs. Each of
these AVPs follows - in the DiameterIdentity order in which they are specified -
including their headers and padding. The AVP Length field is guaranteed
set to be unique per
host.

A Diameter node MAY advertise different identities on each
connection, via the CER and CEA's Origin-Host AVP, but the same
identity MUST be used throughout 8 (12 if the duration of a connection.

When comparing AVPs of this format, it 'V' bit is necessary to add any
absent fields with enabled) plus the default values prior total length
of all included AVPs, including their headers and padding.

4.4 Derived AVP Data Formats

In addition to the comparison.

Calhoun et al. expires December 2001 [Page 32]

Internet-Draft June 2001

For example, diameter-host.abc.com would be expanded to
aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp.

Enumerated
Enumerated is AVP Base Data Formats, applications may define
data formats derived from the Integer32 AVP Base Format. This
contains a list of valid values and their interpretation and is
described in the Diameter Data Formats. New AVP Derived
Data Formats MUST be registered with IANA.

An application introducing the AVP.

4.5 Grouped that uses AVP Values

The Diameter Derived Data Formats other than those
defined in the base protocol allows AVP values MUST have a section "AVP Derived Data
Formats" that includes each of type 'Grouped.' This
implies these formats. In that the Data field section, each
format is actually either defined or listed with a sequence of AVPs. It is
possible reference to include an the RFC that
defines this format. If the AVP with a Grouped type within Derived Data Format is defined, it
SHOULD use a Grouped type,
that is, format similar 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. format definitions below.

The below AVP Code numbering space of all AVPs included in a Grouped AVP Derived DATA Formats are commonly used by applications.

IPAddress
The IPAddress format is derived from the same as for non-grouped AVPs. Further, if any OctetString AVP Base
Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) [16]
address, most significant octet first. The format of the AVPs
encapsulated within a Grouped AVP has
address (IPv4 or IPv6) is determined by the 'M' (mandatory) bit set, length. If the Grouped AVP itself MUST also include
attribute value is an IPv4 address, the 'M' bit set.

All AVPs included in a Grouped AVP Every Grouped AVP defined Length field 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 12 (16 if 'V' bit is enabled), otherwise 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 Length
field MUST be set to 24 (28 if the Grouped AVP

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

required = [qual] "{" avp-spec "}" 'V' bit is enabled) for IPv6
addresses.

Time
The Time format is derived from the Unsigned32 AVP Base Format.

Calhoun et al. expires December 2001 January 2002 [Page 33] 31]

Internet-Draft June July 2001

optional = [qual] "[" avp-name "]"
; The avp-name

This is 32 bit unsigned value containing the four most
significant octets returned from NTP [18], in network byte
order.

This represent the 'optional' rule cannot
; evaluate number of seconds since 0h on 1 January 1900
with respect to any AVP Name which is included
; in the Coordinated Universal Time (UTC).

On 6h 28m 16s UTC, 7 February 2036 the time value will
overflow. NTP [18] describes a fixed or required rule.

qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 section 6.6.
; procedure to extend the time to
2104.

UTF8String
The absence of any qualifiers implies that
; one and only one such UTF8String format is derived from the OctetString AVP MUST be present.
;
; NOTE: "[" and "]" have Base
Format. This is a different meaning
; than in ABNF (see human readable string represented using the optional rule, above).
; These braces cannot be used to express
; optional fixed rules (such
ISO/IEC IS 10646-1 character set, encoded as an optional
; ICV at the end.) To do this, OctetString
using the convention
; is '0*1fixed'.

min = 1*DIGIT
; The minimum number of times UTF-8 [29] transformation format described in RFC
2279.

Since additional code points are added by amendments to the element may
; be present.

max = 1*DIGIT
;
10646 standard from time to time, implementations MUST be
prepared to encounter any code point from 0x00000001 to
0x7fffffff. Byte sequences that do not correspond to the valid
UTF-8 encoding of a code point or are outside this range are
prohibited. Note that since a code point of 0x00000000 is
prohibited, no octet will contain a value of 0x00.

The maximum number use of times the element may
; control codes SHOULD be present.

avp-spec = name-fmt
; The avp-spec has avoided. When it is
necessary to be an AVP Name, defined
; in represent a newline, the base or extended Diameter
; specifications.

avp-name = avp-spec | "AVP"
; control code sequence CR
LF SHOULD be used.

The string "AVP" stands for *any* arbitrary
; AVP Name, which does use of leading or trailing white space SHOULD be avoided.

For code points not conflict with the
; required directly supported by user interface
hardware or fixed position AVPs defined software, an alternative means of entry and
display, such as hexadecimal, MAY be provided.

For information encoded in
; 7-bit US-ASCII, the command UTF-8 encoding
is identical to the US-ASCII encoding.

UTF-8 may require multiple bytes to represent a single
character / code definition.

4.5.1 Example AVP with point; thus the length of a Grouped Data type

The Example AVP (AVP Code 999999) is UTF8String in
octets may be different from the number of type Grouped and characters encoded.

Note that the size of an UTF8String is used to
clarify how Grouped AVP values work. measured in octets, not
characters.

The Grouped Data field has the
following ABNF grammar:

Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host }
1*{ Session-Id }
*[ AVP ] UTF8String MUST not contain any octets with a value of
zero.

Calhoun et al. expires December 2001 January 2002 [Page 34] 32]

Internet-Draft June July 2001

An Example AVP with Grouped Data follows.

DiameterIdentity
The Origin-Host AVP DiameterIdentity format is required. derived from the OctetString AVP
Base Format. It uses the UTF-8 encoding and has the same
requirements as the UTF8String. In this case:

Origin-Host = "example.com".

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

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

Session-Id follow
the Uniform Resource Identifiers (URI) syntax [29] rules
specified below:

Diameter-Identity =
"grump.example.com:33054;23561;2358;0AF3B82"

optional AVPs included are

Recovery-Policy fqdn [ port ] [ transport ]
[ protocol ]

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

Futuristic-Acct-Record ( "diameter" | "radius" | "tacacs+" )

protocol = <binary>
fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
d3427475e49968f841

The data for ";protocol=" aaa-protocol
; If absent, the optional AVPs default AAA protocol
; is represented in hex since the format diameter.

fqdn = Fully Qualified Host Name

port = ":" 1*DIGIT
; One of these AVPs is neither known at the time of definition ports used to listen for
; incoming connections. ; If absent,
; the default Diameter port (TBD) is
; assumed.

transport-protocol = ( "tcp" | "sctp" | "udp" )

transport = ";transport=" transport-protocol

; One of the
Example-AVP group, nor (likely) at transports used to listen
; for incoming connections. If absent,
; the time default SCTP [26] protocol is
; assumed. UDP MUST NOT be used when
; the example instance
of this AVP aaa-protocol field is interpreted - except by Diameter implementations which
support the same set of AVPs. to
; diameter.

The encoding example illustrates how
padding is used, how length fields following are calculated and how AVPs do not
have to begin examples of valid Diameter host
identities:

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

Since multiple Diameter processes on 8 byte boundaries. Also note that AVPs may be
present in the Grouped AVP value which the receiver a single host cannot interpret
(here,
listen for incoming connections on the Recover-Policy and Futuristic-Acct-Record AVPs).

This AVP would same port on a given
protocol, the DiameterIdentity is guaranteed to be encoded as follows: unique per

Calhoun et al. expires December 2001 January 2002 [Page 35] 33]

Internet-Draft June July 2001

host.

A Diameter node MAY advertise different identities on each
connection, via the CER and CEA's Origin-Host AVP, but the same
identity MUST be used throughout the duration of a connection.

When comparing AVPs of this format, it is necessary to add any
absent fields with the default values prior to the comparison.
For example, diameter-host.abc.com would be expanded to
aaa://diameter/diameter-host.abc.com:TBD;protocol=sctp.

Enumerated
Enumerated is derived from the Integer32 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.6 Diameter Base Protocol AVPs

The following table describes Format. This
contains a list of valid values and their interpretation and is
described in the Diameter AVPs defined in application introducing the base
protocol, their AVP.

IPFilterRule
The IPFilterRule format is derived from the OctetString AVP Code values, types, possible flag values
Base Format. It uses the UTF-8 encoding and
whether has the AVP MAY same
requirements as the UTF8String. Packets may be encrypted.

Calhoun et al. expires December 2001 [Page 36]

Internet-Draft June 2001

+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type filtered based
on the following information that is associated with it:

Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
TCP flags
IP fragment flag
IP options
ICMP types

Rules for the appropriate direction are evaluated in order,
with the first matched rule terminating the evaluation. Each
packet is evaluated once. If no rule matches, the packet is
dropped if the last rule evaluated was a permit, and passed if
the last rule was a deny.

IPFilterRule filters MUST follow the format:

action dir proto from src to dst [options]

action permit - Allow packets that match the rule.
deny - Drop packets that match the rule.

dir "in" is from the terminal, "out" is to the
terminal.

proto An IP protocol specified by number. The "ip"

Calhoun et al. expires January 2002 [Page 34]

Internet-Draft July 2001

keyword means any protocol will match.

src and dst <address/mask> [ports]

The <address/mask> may be specified as:
ipno An IPv4 or IPv6 number in dotted-
quad or canonical IPv6 form. Only
this exact IP number will match the
rule.
ipno/bits An IP number as above with a mask
width of the form 1.2.3.4/24. In
this case all IP numbers from
1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the
IP version and the IP number MUST
NOT have bits set beyond the mask.

The sense of the match can be inverted by
preceding an address with the not modifier,
causing all other addresses to be matched
instead. This does not affect the selection of
port numbers.

The keyword "any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned" is the
address or set of addresses assigned to the
terminal. The first rule SHOULD be "deny in
ip !assigned".

With the TCP, UDP and SCTP protocols, optional
ports may be specified as:

{port|port-port}[,port[,...]]

The `-' notation specifies a range of ports
(including boundaries).

Fragmented packets which have a non-zero offset
(i.e. not the first fragment) will never match
a rule which has one or more port
specifications. See the frag option for
details on matching fragmented packets.

options:
frag Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or
TCP/UDP port specifications.

Calhoun et al. expires January 2002 [Page 35]

Internet-Draft July 2001

ipoptions spec
Match if the IP header contains the comma
separated list of options specified in spec. The
supported IP options are:

ssrr (strict source route), lsrr (loose source
route), rr (record packet route) and ts
(timestamp). The absence of a particular option
may be denoted with a `!'.

tcpoptions spec
Match if the TCP header contains the comma
separated list of options specified in spec. The
supported TCP options are:

mss (maximum segment size), window (tcp window
advertisement), sack (selective ack), ts (rfc1323
timestamp) and cc (rfc1644 t/tcp connection
count). The absence of a particular option may
be denoted with a `!'.

established
TCP packets only. Match packets that have the RST
or ACK bits set.

setup TCP packets only. Match packets that have the SYN
bit set but no ACK bit.

tcpflags spec
TCP packets only. Match if the TCP header
contains the comma separated list of flags
specified in spec. The supported TCP flags are:

fin, syn, rst, psh, ack and urg. The absence of a
particular flag may be denoted with a `!'. A rule
which contains a tcpflags specification can never
match a fragmented packet which has a non-zero
offset. See the frag option for details on
matching fragmented packets.

icmptypes types
ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any
combination of ranges or individual types
separated by commas. The supported ICMP types
are:

echo reply (0), destination unreachable (3),

Calhoun et al. expires January 2002 [Page 36]

Internet-Draft July 2001

source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17)
and address mask reply (18).

There is one kind of packet that the access device MUST always
discard, that is an IP fragment with a fragment offset of one.
This is a valid packet, but it only has one use, to try to
circumvent firewalls.

An access device that is unable to interpret or apply a deny
rule MUST terminate the session. An access device that is
unable to interpret or apply a permit rule MAY apply a more
restrictive rule. An access device MAY apply deny rules of
its own before the supplied rules, for example to protect
the access device owner's infrastructure.

The rule syntax is a modified subset of ipfw(8) from FreeBSD,
and the ipfw.c code may provide a useful base for
implementations.

QoSFilterRule
The QosFilterRule format is derived from the OctetString AVP
Base Format. It uses the UTF-8 encoding and has the same
requirements as the UTF8String. Packets may be marked or
metered based on the following information that is associated
with it:

Direction (in or out)
Source and destination IP address (possibly masked)
Protocol
Source and destination port (lists or ranges)
DSCP values (no mask or range)

QoSFilterRule filters MUST follow the format:

action dir proto from src to dst [options]

tag - Mark packet with a specific DSCP [49].
The DSCP option MUST be included.

Calhoun et al. expires January 2002 [Page 37]

Internet-Draft July 2001

meter - Meter traffic. The metering options
MUST be included.

dir "in" is from the terminal, "out" is to the
terminal.

proto An IP protocol specified by number. The "ip"
keyword means any protocol will match.

src and dst <address/mask> [ports]

The sense of the match can be inverted by
preceding an address with the not modifier,
causing all other addresses to be matched
instead. This does not affect the selection of
port numbers.

The keyword "any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned" is the
address or set of addresses assigned to the
terminal. The first rule SHOULD be "deny in
ip !assigned".

With the TCP, UDP and SCTP protocols, optional
ports may be specified as:

{port|port-port}[,port[,...]]

The `-' notation specifies a range of ports
(including boundaries).

options:

DSCP <color>
color values as defined in [49]. Exact matching

Calhoun et al. expires January 2002 [Page 38]

Internet-Draft July 2001

of DSCP values is required (no masks or ranges).
the "deny" can replace the color_under or
color_over values in the meter action for rate-
dependent packet drop.

metering <rate> <color_under> <color_over>
The metering option provides Assured Forwarding,
as defined in [50], and MUST be present if the
action is set to meter. The rate option is the
throughput, in bits per second, which is used by
the access device to mark packets. Traffic above
the rate is marked with the color_over codepoint,
while traffic under the rate is marked with the
color_under codepoint. The color_under and
color_over options contain the drop preferences,
and MUST conform to the recommended codepoint
keywords described in [50] (e.g. AF13).

The metering option also supports the strict
limit on traffic required by Expedited
Forwarding, as defined in [51]. The color_over
option may contain the keyword "drop" to prevent
forwarding of traffic that exceeds the rate
parameter.

The rule syntax is a modified subset of ipfw(8) from FreeBSD,
and the ipfw.c code may provide a useful base for
implementations.

4.5 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.

The AVP Code numbering space of all AVPs included in a Grouped AVP is
the same as for non-grouped AVPs. Further, if any of the AVPs
encapsulated within a Grouped AVP has the 'M' (mandatory) bit set,
the Grouped AVP itself MUST also include the 'M' bit set.

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

Calhoun et al. expires January 2002 [Page 39]

Internet-Draft July 2001

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.
;
; 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

Calhoun et al. expires January 2002 [Page 40]

Internet-Draft July 2001

; 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.5.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"

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

Calhoun et al. expires January 2002 [Page 41]

Internet-Draft July 2001

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 January 2002 [Page 42]

Internet-Draft July 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.6 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 January 2002 [Page 43]

Internet-Draft July 2001

+---------------------+
| AVP Flag rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
Accounting- 482 13.2 9.8.2 Unsigned32 | M | P | | V | Y |
Interim-Interval | | | | | |
Accounting- 50 13.5 9.8.5 OctetString| M | P | | V | Y |
Multi-Session-Id | | | | | |
Accounting- 485 13.3 9.8.3 Unsigned32 | M | P | | V | Y |
Record-Number | | | | | |
Accounting- 480 13.1 Unsigned32 9.8.1 Enumerated | M | P | | V | Y |
Record-Type | | | | | |
Accounting- 44 13.4 9.8.4 OctetString| M | P | | V | Y |
Session-Id | | | | | |
Acct- 259 6.10 Integer32 | M | | | V | N |
Application-Id | | | | | |
Alternate-Peer 275 5.3.8 OctetString| M | | | V | N |
Auth- 258 6.6 6.9 Integer32 | M | | | V | N |
Application-Id | | | | | |
Auth-Request- 274 8.7 Enumerated | M | | | V | N |
Type | | | | | |
Authorization- 291 10.8 8.9 Unsigned32 | M | P | | V | N |
Lifetime | | | | | |
Auth-Grace- 276 8.10 Unsigned32 | M | P | | V | N |
Period | | | | | |
Auth-Session- 277 8.11 Enumerated | M | P | | V | N |
State | | | | | |
Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N |
Type | | | | | |
Class 25 10.16 8.20 OctetString| M | P | | V | Y |
Destination-Host 293 5.6 6.6 OctetString| M | | | V | N |
Destination- 283 5.7 6.7 OctetString| M | | | V | N |
Realm | | | | | |
Disconnect-Cause 273 5.4.3 Enumerated | M | | | V | N |
Error-Message 281 9.3 7.3 OctetString| | | | V | N |
Error-Reporting- 294 9.4 7.4 OctetString| | | | V | N |
Host | | | | | |
Failed-AVP 279 9.5 7.5 OctetString| M | P | | V | Y N |
Firmware- 267 6.5 5.3.4 Unsigned32 | | | | V,M | N |
Revision | | | | | |
Host-IP-Address 257 6.7 5.3.5 IPAddress | M | | | V | N |
Multi-Round- 272 10.15 8.19 Unsigned32 | M | P | | V | Y |
Time-Out | | | | | |
Origin-Host 264 5.4 6.4 OctetString| M | | | V | N |
Origin-Realm 296 5.5 6.5 OctetString| M | | | V | N |
-----------------------------------------|----+-----+----+-----|----|

Calhoun et al. expires January 2002 [Page 44]

Internet-Draft July 2001

Calhoun et al. expires December 2001 [Page 37]

Internet-Draft June 2001

5.0 Diameter message processing Peers

This section describes how a Diameter nodes establish connections and
communicate with peers.

5.1 Peer Connections

Although a Diameter node may have many possible peers that it is able
to communicate with, it may not be economical to have an established
connection to all of them. At a minimum, a Diameter node SHOULD have
an established connection with a primary and secondary peer, and MAY
have additional connections, if it is deemed necessary.

Calhoun et al. expires January 2002 [Page 45]

Internet-Draft July 2001

When a peer is deemed suspect, which could occur for various reasons,
including not receiving a DWA within an alloted timeframe, no new
requests should be forwarded to the peer, but failover procedures are
not invoked. When an active peer is moved to this mode, additional
connections SHOULD be established to ensure that the necessary number
of active connections exists.

There are two ways that a peer is removed from the suspect peer list:
1. The peer is no longer reachable, causing the transport
connection to be shutdown. The peer is moved to the closed
state.
2. Three watchdog messages are exchanged with accepted round trip
times, and the connection to the peer is considered stabilized.

5.2 Diameter Peer Discovery

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

There are two cases where Diameter peer discovery may be performed.
The first is when a Diameter client needs to discover a first-hop
Diameter agent. The second case is when a Diameter agent needs to
discover another agent - for further handling of a Diameter
operation. In both cases, the following 'search order' is
recommended:

1. The Diameter implementation consults its list of static
(manual) configured Diameter agent locations. These will be
used if they exist and respond.

2. The Diameter implementation uses SLPv2 [28] to discover
Diameter services. The Diameter service template [32] is
included in Appendix A. It is recommended that SLPv2 security
be deployed (this requires distributing keys to SLPv2 agents.)
This is discussed further in Appendix A.

SLPv2 will allow Diameter implementations to discover the
location of Diameter agents in the 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.

3. The Diameter implementation uses DNS to request the SRV RR [33]
for the '_diameter._sctp' and/or '_diameter._tcp' server in a

Calhoun et al. expires January 2002 [Page 46]

Internet-Draft July 2001

particular domain. The Diameter implementation has to know in
advance which domain to look for a Diameter agent in. This section describes how
could be deduced, for example, from the 'realm' in a NAI that a
Diameter requests implementation needed to perform a Diameter operation
on.

3.1 If the destination address is a numeric IP address, the
requestor contacts the peer at the given address and answers the
port number specified in the SRV record or, if not
specified, the default port (TBD).

3.2 The results of the query or queries are merged and ordered
based on priority. Then, the searching technique outlined in
[46] is used to select servers in order. The requestor
attempts to contact each peer in the order listed, at the
port number specified in the SRV record. If none of the
servers can be contacted, the requestor gives up. If there
are no SRV records, DNS address records are used, as
described below.

3.3 If there are no SRV records, the requestor queries the DNS
server for address records for the destination address
'_diameter._sctp'.domain or '_diameter._tcp'.domain. Address
records include A RR's, AAAA RR's, A6 RR's or other similar
records, chosen according to the requestor's network
protocol capabilities.

If the DNS server returns no address records, the requestor
gives up. If there are created
and processed.

5.1 address records, the same rules as in
step 3.2 apply.

Requestors MUST NOT cache query results except according to the
rules in [47]. Diameter request routing overview

A request is sent towards its final destination using a combination
of allows AAA peers to protect the Destination-Realm
integrity and Destination-Host AVPs, in one privacy of these
three combinations:
- a request that is not proxiable (such communication as well as CER) MUST NOT contain
either Destination-Realm or Destination-Host AVPs.
- a request that needs to be sent perform
end-point authentication. Still, it is prudent to employ DNS
Security as a home server serving a
specific realm, but not precaution when using DNS SRV RRs to a specific server (such as look up the first
request of a series
location of round-trips), MUST contain a
Destination-Realm AVP, but MUST NOT contain a Destination-Host
AVP.
- a request that needs Diameter agent [34, 35, 36].

A dynamically discovered peer causes an entry in the Peer Table (see
section 2.6) to be sent to a specific home server among
those serving created. Note that entries created via DNS MUST
expire (or be refreshed) within the DNS TTL. If a given peer is discovered
outside of the local realm, MUST contain both a routing table entry (see Section 2.7)
for the Destination-
Realm and Destination-Host AVPs.

The Destination-Host AVP peer's realm is used created. The routing table entry's expiration
MUST match the peer's expiration value.

5.3 Capabilities Exchange

Calhoun et al. expires January 2002 [Page 47]

Internet-Draft July 2001

When two Diameter peers establish a transport connection, they MUST
exchange the Capabilities Exchange messages, as described above when specified in the
destination peer
state machine (see section 5.6). This message allows the discovery of
a peer's identity and its capabilities (protocol version number,
supported Diameter applications, etc.)

The receiver only issues commands to its peers that have advertised
support for the request is fixed, which includes:

Calhoun et al. expires December 2001 [Page 38]

Internet-Draft June 2001

- Authentication requests Diameter application that span multiple round trips
- defines the command. A
Diameter message node MUST cache the supported applications in order to
ensure that uses unrecognized commands and/or AVPs are not unnecessarily
sent to a security mechanism that makes use peer.

A receiver of a pre-established session key shared between the source and
the final destination of Capabilities-Exchange-Req (CER) message which does
not have any applications in common with the message.
- Server initiated messages that sender MUST be received by return a specific
Diameter client (e.g. access device), such as
Capabilities-Exchange-Answer (CEA) with the Abort-
Session-Request message, which is used Result-Code AVP set to request that a
particular user's session be terminated.
DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport
layer connection. Note that an agent can forward receiving a request to CER or CEA from a host described in the
Destination-Host AVP only if the host in question is included in its peer table (see sections 5.1.4 and 5.1.5). Otherwise, the request is
routed based on the Destination-Realm only
advertising itself as a Relay (see sections 5.1.6 and
5.1.7).

The Destination-Realm AVP MUST be present if the message is routable.
A message that section 2.5) MUST NOT be relayed, proxied or redirected MUST NOT
include interpreted
as having common applications with the Destination-Realm in its ABNF. peer.

The value of the
Destination-Realm AVP MAY CER and CEA messages MUST NOT be extracted from the User-Name AVP, proxied, or
other application-specific methods.

When redirected.

Since the CER/CEA messages cannot be proxied, it is still possible
that an upstream proxy receives a message is received, for which it has no
available peers to handle the message application that corresponds to the
Command-Code. In such instances, the 'E' bit is processed set in the following
order:
1. If the answer
message is destined for (see Section 7.2) to inform the local host, downstream to take action
(e.g. re-routing request to an alternate peer).

With the procedures
listed in section 5.1.1 are followed.
2. If exception of the Capabilities-Exchange-Request message, a
message is intended for of type Request that includes the Auth-Application-Id or
Acct-Application-Id AVPs, or a Diameter peer message with whom the
local host is able an application-specific
command code, MAY only be forwarded to directly communicate with, a host that has explicitly
advertised support for the procedures
listed in section 5.1.2 are followed. This is known as Message
Forwarding.
3. The procedures listed in section 5.1.4 are followed, which is
known as Message Routing.
4. If none of application (or has advertised the above are successful, an answer is returned with Relay
Application Identifier).

5.3.1 Capabilities-Exchange-Request

The Capabilities-Exchange-Request (CER), indicated by the Result-Code Command-
Code set to DIAMETER_UNABLE_TO_DELIVER.

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, 257 and still be in compliance with the protocol specification.

5.1.1 Originating Command Flags' 'R' bit set, is sent to inform
a Request peer that a reboot has occurred. Upon detection of a transport
failure, this message MUST NOT be sent to an alternate peer.

When creating a request, in addition Diameter is run over SCTP [26], which allows for connections to any other procedures
described in
span multiple interfaces, hence multiple IP addresses, the application definition
Capabilities-Exchange-Request message MUST contain one Host-IP-
Address AVP for each potential IP address that specific request,
the following procedures MUST MAY be followed:
- locally used

Calhoun et al. expires January 2002 [Page 48]

Internet-Draft July 2001

when transmitting Diameter messages.

Message Format

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

5.3.2 Capabilities-Exchange-Answer

The Capabilities-Exchange-Request (CEA), indicated by the Command-Code should be Command-
Code set to 257 and the appropriate value
- the Command Flags' 'R' bit should be set
- the End-to-End Identifier should be set cleared, is sent in
response to a CER message.

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

Message Format

Calhoun et al. expires December 2001 January 2002 [Page 39] 49]

Internet-Draft June July 2001

value
- the

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

5.3.3 Vendor-Id AVP

The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and Origin-Realm AVPs MUST be set to contains
the
appropriate values, used IANA "SMI Network Management Private Enterprise Codes" [2] value
assigned to identify the source vendor of the message
- Diameter device.

In combination with the Destination-Host and Destination-Realm AVPs MUST Supported-Vendor-Id AVP (section 5.3.6), this
MAY be set to
the appropriate values as described used in section 5.1.

5.1.2 Sending a Request

When sending a request, either originated locally, or as the result
of a forwarding or routing operation, the following procedures MUST
be followed:
- the Hop-by-Hop Identifier should be set order to a locally unique
value
- the message should know which vendor specific attributes may be saved in the list of pending requests

Other actions
sent to perform on the message based on the particular role the agent peer. It is playing are described in also envisioned that the following sections.

5.1.3 Processing Local Requests

A request is known to be for local comsumption when one combination of the
following conditions occur:
- The Destination-Host AVP contains the local host's identity,
- The Destination-Host AVP is not present, the Destination-Realm
AVP contains a realm the server is configured to process
locally,
Vendor-Id, Product-Name (section 5.3.7) and the Diameter application is locally supported, or
- The Destination-Realm AVP is not present.

When a request is locally processed, the rules Firmware-Revision
(section 5.3.4) AVPs MAY provide very useful debugging information.

A Vendor-Id value of zero in section 5.2 should
be used to generate the corresponding answer.

5.1.4 Request Forwarding

Request forwarding CER or CEA messages is done using reserved and
indicates that the Diameter Peer Table. The
Diameter peer table contains all of is in the peers experimental or concept
stage and that an IANA Private Enterprise Number has yet to be
obtained by the local node implementor.

5.3.4 Firmware-Revision AVP

The Firmware-Revision AVP (AVP Code 267) is
able of type Unsigned32 and is
used to directly communicate with.

When inform a request is received, and Diameter peer of the host encoded in firmware revision of the Destination-
Host AVP is one
issuing device.

For devices that is present in the peer table, do not have a firmware revision (general purpose
computers running Diameter software modules, for instance), the message SHOULD
be forwarded to
revision of the peer.

5.1.5 Peer Table

The Diameter Peer Table is used in message forwarding, and referenced software module may be reported instead.

5.3.5 Host-IP-Address AVP

Calhoun et al. expires December 2001 January 2002 [Page 40] 50]

Internet-Draft June July 2001

by the Domain Routing Table. A Peer Table entry contains the
following fields:
- Host identity, following

The Host-IP-Address AVP (AVP Code 257) is of type IPAddress and is
used to inform a Diameter peer of the conventions described for sender's IP address. All
source addresses that a Diameter node expects to use with SCTP [26]
MUST be advertised in the
DiameterIdentity derived CER and CEA messages by including a Host-
IP-Address AVP data format in section 4.4. for each address. This
MAY AVP MUST ONLY be resolved locally, or dynamically updated via used in the
CER and CEA messages.

5.3.6 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 Origin-
Host AVP of device vendor. This is
used in the CER or and CEA messages.
- TLS Enabled. Specifies whether TLS is messages in order to be used when
communicating with inform the peer.
- Additional security information, when needed (e.g. keys,
certificates)

5.1.6 Request Routing

Diameter request message routing is done via realms. A Diameter
message peer that is proxyable MUST include the target realm in
sender supports a subset of the
Destination-Realm vendor-specific commands and/or AVPs
defined by the vendor identified in this AVP.

5.3.7 Product-Name AVP

The realm MAY be retrieved from the User-Name
AVP, which Product-Name AVP (AVP Code 269) is in the form of a Network Access Identifier (NAI). type UTF8String, and
contains the vendor assigned name for the product. The
realm portion of Product-Name
AVP SHOULD remain constant across firmware revisions for the NAI same
product.

5.3.8 Alternate-Peer AVP

The Alternate-Peer AVP (AVP Code 275) is inserted in the Destination-Realm AVP.

Diameter agents MAY have a list of locally supported realms, type DiameterIdentity,
and MAY
have a list of externally supported realms. When a request is
received that includes a realm that is not locally supported, the
message is routed to contains the URI of an alternate peer configured that MAY be used in the Domain Routing Table
table (see section 5.1.7).

5.1.7 Realm-Based Routing Table

All Realm-Based
server-initiated requests, when routing lookups are performed against what is
commonly known as using the Domain Routing Table (see section 16.0). A
Domain Routing Table Entry contains Source-Route AVP.

5.4 Disconnecting Peer connections

When a Diameter node disconnects one its transport connections, its
peer cannot know the following fields:
- Realm Name. This is reason for the field disconnect, and will most likely
assume that is typically used as a
primary key connectivity problem occurred, or that the peer has
rebooted. In these cases, the peer may periodically attempt to
reconnect, as stated in section 2.1. In the routing table lookups. Note event that some
implementations perform their lookups based on longest-match-
from-the-right on the realm rather than requiring an exact
match.
- Application Identifier. It is possible for disconnect
was a routing entry to
have result of either a different destination based on the Acct-Application-Id
(for accounting messages) or Auth-Application-Id (for non-
accounting messages) shortage of internal resources, or simply
that the message. This field is typically
used as a secondary key field node 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 - question has no intentions of forwarding any
Diameter messages that resolve to a routing entry
with the Local Action set to Local can be satisfied
locally, and do peer in the foreseeable future, a periodic
connection request would not need to be routed to another server.
2. RELAY - All welcomed. The Disconnection-Reason
AVP contains the reason the Diameter messages that fall within this node issued the Disconnect-
Peer-Request message.

The Disconnect-Peer-Request message is used by a Diameter node to

Calhoun et al. expires December 2001 January 2002 [Page 41] 51]

Internet-Draft June July 2001

category MUST be routed

inform its peer of its intent to disconnect the transport layer, and
that the peer shouldn't reconnect unless it has a next hop server, without
modifying any non-routing AVPs. See section 5.1.9 for
relaying guidelines
3. PROXY - All Diameter valid reason to do
so (e.g. message to be forwarded). Upon receipt of the message, the
Disconnect-Peer-Answer is returned, which SHOULD contain an error if
messages that fall within this
category MUST have recently be routed to forwarded, and are likely in flight, which
would otherwise cause a next hop server. race condition.

The local
server MAY apply its local policies to receiver of the message Disconnect-Peer-Answer initiates the transport
disconnect.

5.4.1 Disconnect-Peer-Request

The Disconnect-Peer-Request (DPR), indicated by
including new AVPs the Command-Code set
to 282 and the message prior Command Flags' 'R' bit set, is sent to routing. See
section 5.1.9 for relaying guidelines.
4. REDIRECT - Diameter messages that fall within this
category MUST have a peer to
inform its intentions to shutdown the identity transport connection. Upon
detection of the home a transport failure, this message MUST NOT be sent to an
alternate peer.

Message Format

<Disconnect-Peer-Request> ::= < Diameter
server(s) appended, and returned Header: 282, REQ >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Disconnect-Cause }

5.4.2 Disconnect-Peer-Answer

The Disconnect-Peer-Answer (DPA), indicated by the Command-Code set
to 282 and the sender of Command Flags' 'R' bit cleared, is sent as a response
to the Disconnect-Peer-Request message. See section 5.1.8 for redirect guidelines.
- Server Identifier - One or more servers Upon receipt of this message,
the message transport connection is to be
routed to. These servers shutdown.

Message Format

<Disconnect-Peer-Answer> ::= < Diameter Header: 282 >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }

5.4.3 Disconnect-Cause AVP

The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
Diameter node MUST also be present include this AVP in the Peer
table. When the Local Action is set Disconnect-Peer-Request
message to RELAY or PROXY, this
field contains inform the identity peer of the server(s) reason for its intention to

Calhoun et al. expires January 2002 [Page 52]

Internet-Draft July 2001

shutdown the transport connection. The following values are
supported:

REBOOTING 0
A scheduled reboot is imminent.

BUSY 1
The peer's internal resources are constrained, and it has
determined that the message must transport connection needs to be
routed to. When shutdown.

DO_NOT_WANT_TO_TALK_TO_YOU 2
The peer has determined that it does not see a need for the Local Action field is set
transport connection to REDIRECT, this
field contains exist, since it does not expect any
messages to be exchanged in the identity foreseeable future.

5.5 Transport Failure Detection

Given the nature of one or more servers the message
should be redirected to.

It Diameter protocol, it is important to note recommended that Diameter agents MUST support at least
one of
transport failures be detected as soon as possible. Detecting such
failures will minimize the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents
do not need to support all modes occurrence of operation in order messages sent to conform
with the protocol specification, but MUST follow the protocol
compliance guidelines unavailable
agents, resulting in section 2.0. Relay agents MUST NOT reorder
AVPs, unnecessary delays, and proxies SHOULD NOT reorder AVPs. will provide better
failover performance. The routing table MAY include a default entry which MUST be Device-Watchdog-Request and Device-
Watchdog-Answer messages, defined in this section, are used for
any requests not matching any of the other entries. to pro-
actively detect transport failures.

5.5.1 Device-Watchdog-Request

The routing table
MAY consist of only such an entry.

When a request is routed, the target server MUST have advertised Device-Watchdog-Request (DWR), indicated by the
Application Identifier (see section 6.1) for Command-Code set
to 280 and the given message, or
have advertised itself as a relay or proxy agent.

5.1.8 Redirecting requests

When a redirector agent receives a request whose routing entry Command Flags' 'R' bit set, is set sent to REDIRECT, it a peer when no
traffic has been exchanged between two peers (see Section 5.5.3).
Upon detection of a transport failure, this message MUST answer the request with Message-Reject-Answer,
while maintaining the Hop-by-Hop Identifier in NOT be sent
to an alternate peer.

Message Format

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

5.5.2 Device-Watchdog-Answer

The Device-Watchdog-Answer (DWA), indicated by the header, Command-Code set
to 280 and
include the Result-Code AVP Command Flags' 'R' bit cleared, is sent as a response
to DIAMETER_REDIRECT_INDICATION. Each of
the servers associated with the routing entry are added in separate
Redirect-Host AVP. Device-Watchdog-Request message.

Calhoun et al. expires December 2001 January 2002 [Page 42] 53]

Internet-Draft June July 2001

+------------------+
|

Message Format

<Device-Watchdog-Answer> ::= < Diameter |
| Redirector Agent |
+------------------+
^ |
1. Request | | 2. MRA +
joe@xyz.com | | Header: 280 >
{ 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 servers }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }

5.5.3 Transport Failure Algorithm

The watchdog behavior is controlled by an algorithm defined in
the Redirect-Host AVP(s). These certificates this
section. Note that implementations are encapsulated in not restricted to the
algorithm defined herein, but SHOULD implement an algorithm that
produces similar results. In this section, we will refer to a
CMS-Cert AVP [11].

The receiver of memory
control structure that contains all information regarding a specific
peer as a Peer Control Block, or PCB.

For the MRA message with purposes of illustrating the Result-Code AVP set to
DIAMETER_REDIRECT_INDICATION uses algorithm, each PCB contains the hop-by-hop
following fields:

Status - This field in the
Diameter header to identify represents the request level of confidence in the pending message queue
(see Section 7.3) that is to be redirected. If no transport
connection exists with
algorithm. The following values are defined:

OKAY indicates the new agent, one connection is created, and presumed working
WAIT_DWA indicates that a DWR has been sent but a DWA
has not yet been received
SUSPECT indicates the request connection is sent directly to it.

5.1.9 Relaying and Proxying Requests

A relay possibly
congested or proxy agent MUST check for forwarding loops before
forwarding down

Pending - This boolean field is set to TRUE when there are no
outstanding unanswered requests. A loop

T is detected if the server finds its own
address watchdog timer, measured in a Route-Record AVP. seconds. Every second, T is
decremented. When such an event occurs, the agent
MUST answer with it reaches 0, the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

A relay or proxy agent MUST append a Route-Record AVP that includes
its identity to all requests forwarded. OnTimerElapsed event (see below)
is invoked.

The last Route-Record AVP in
all requests received MUST be validated, by ensuring that algorithm uses the host
encoded following time constants, which have default
values but may be configured differently in an implementation:

Ti, the AVP is the same as the peer the message was received
from.

The Hop-by-Hop identifier in idle time, represents the request number of seconds that must
elapse when there is saved, and replaced with no activity, before a locally unique value. DWR is sent. The source
default value of the request Ti is also saved,
which includes 30 seconds. In order to avoid
synchronization behaviors that can occur with fixed timers among
distributed systems, each time Ti is calculated with a jitter by
using the IP address, port Ti configured (or default) value and protocol.

Relay randomly adding or
subtracting a random value drawn between 0.5 and Proxy agents MAY include the Proxy-Info AVP in requests if
it requires access any local state information when the corresponding
response is received. Alternatively, it MAY simply use local storage 2 seconds.

Calhoun et al. expires December 2001 January 2002 [Page 43] 54]

Internet-Draft June July 2001

Alternative calculations to store state information.

The message is then forwarded to the next hop, as identified in create jitter MAY be used. These MUST
be pseudo-random and not cyclic.

Tr, the
Domain Routing Table.

Figure 6 provides an example of message routing using request pending time, represents 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)
Figure 6: Routing number of Diameter seconds
that must elapse when there are requests pending but no messages

5.2 Diameter Answer Processing

When an request
have been received, before a DWR is locally processed, the following procedures MUST
be applied to create the associated answer, in addition to any
additional procedures that MAY sent. Tr should be discussed in the Diameter
application defining the command:

- less than
Ti. The same Hop-by-Hop identifier in default value of Tr is 10 seconds.

Tw, the request watchdog pending time, represents the number of seconds
that must elapse after a DWR is used in sent but no DWA has been received,
before the
answer.
- PCB's Status field is set to SUSPECT. The local host's identity default
value of Tw is encoded in 5 seconds.

Td, the Origin-Host AVP.
- The Destination-Host disconnect timer, the number of seconds that must elapse
when the PCB's Status field is set to SUSPECT and Destination-Realm AVPs MUST NOT be
present in no DWA has been
received, before the answer message.
- The Result-Code AVP connection is added with its stopped. The default value indicating success
or failure.
- If of
Td is 5 seconds.

Pseudo-code for the Session-Id algorithm is present in as follows:

/*
* OnSendRequest() is called whenever a request is sent on
* connection
*/
OnSendRequest(pcb)
{
if pcb->Status = OKAY AND T > Tr
T = Tr
}

/*
* OnReceiveNonDWA() is called whenever a message other
* than DWA is received from the request, it MUST peer. This message MAY
* be included
in the answer.
- Any Proxy-Info AVPs in the a request MUST be added to the answer
message, in the same order they were present in the request.

5.2.1 Processing received Answers

A Diameter client or proxy MUST match the Hop-by-Hop Identifier in an
answer answer.
*/
OnReceiveNonDWA(pcb)
{
if pcb->Status = OKAY
if pcb->Pending
T = Tr
else
T = Ti
}

/*
* OnReceiveDWA() is called whenever a DWA is received against the list of pending requests. The
corresponding message should be removed
* from the list of pending peer.
*/

Calhoun et al. expires December 2001 January 2002 [Page 44] 55]

Internet-Draft June July 2001

requests. It SHOULD ignore answers received that do not match a known
Hop-by-Hop Identifier.

5.2.2 Relaying and Proxying Answers

OnReceiveDWA(pcb)
{
if pcb->status = WAIT_DWA OR pcb->Status = SUSPECT
if pcb->Pending
T = Tr
else
T = Ti
}

/*
* OnTimerElapsed() is called by some timer services
* whenever T reaches zero (0).
*/
OnTimerElapsed(pcb)
{
if pcb->status = OKAY
SendWatchdog(pcb)
pcb->status = WAIT_DWA
else if pcb->status = WAIT_DWA
pcb->status = SUSPECT
T = Td
else if pcb->status = SUSPECT
StopConnection(pcb)
FailoverProcedures(pcb)
}

5.5.4 Failover/Failback Procedures

In the answer event that a transport failure is for detected with a peer, it is
necessary for all pending request which was proxied or relayed, the
agent MUST restore the original value of the messages to be forwarded to an
alternate agent, if possible. This is commonly referred to as
failover.

In order for a Diameter header's Hop-
by-Hop Identifier field.

If the last Proxy-Info AVP in node to perform failover procedures, it is
necessary for the node to maintain a pending message queue for a
given peer. When an answer message is targeted to received, the local
Diameter server, corresponding
request is removed from the AVP MUST queue. The Hop-by-Hop Identifier field
MAY be removed before used to match the answer is
forwarded.

If a relay or proxy agent receives an answer with the queued request.

When a Result-Code AVP
indicating transport failure is detected, all messages in the queue are
sent to an alternate agent, if possible. An example of a failure, case where
it MUST NOT modify is not possible for forward the contents of message to an alternate server is
when the AVP. Any
additional local errors detected SHOULD be logged, but not reflected
in message has a fixed destination, and the Result-Code AVP. If unavailable peer is
the message's final destination (see Destination-Host AVP). Such an
error requires that the agent receives return an answer message with
a Result-Code AVP indicating success, the 'E'
bit set and it wishes to modify the Result-Code AVP set to indicate an error, it MUST issue an STR on behalf DIAMETER_UNABLE_TO_DELIVER.

Calhoun et al. expires January 2002 [Page 56]

Internet-Draft July 2001

It is important to note that multiple identical request or answer MAY
be received as a result of the access
device. a failover. The agent MUST then send End-to-End Identifier
field in the answer Diameter header along with the Origin-Host AVP MUST be
used to identify duplicate messages.

As described in section 2.1, a connection request should be
periodically attempted with the host which it received failed peer in order to re-establish
the
original request from.

5.3 Hiding Network Topology

A Relay or Proxy agent routing transport connection. Once a connection has been successfully
established, messages outside of their
administrative domain MAY need can once again be forwarded to hide the internal Diameter
topology. peer. This
is done by removing all Route-Record AVPs in commonly referred to as failback.

5.6 Peer State Machine

This section contains a
request.

5.4 Origin-Host AVP

The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and finite state machine, that MUST be present in observed
by all Diameter messages. 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 AVP identifies state machine is
intended to handle both the
endpoint simple case, in which originated one peer initiates
a connection to the Diameter message, i.e. other, and the complex case, in which each peer
simultaneously initiates a connection to the other. In the complex
case, an election occurs to determine which transport connection will
survive. It is important to note that the access
device, home server, or broker. Relay agents port on which a connection
is initiated MUST NOT modify this
AVP.

The value of be the Origin-Host AVP port Diameter listens for incoming
connections.

I- is guaranteed used to be unique within a
single host.

Note that represent the Origin-Host AVP may resolve to more than one address as initiator (connecting) connection, while
the Diameter peer may support more than one address.

Calhoun et al. expires December 2001 [Page 45]

Internet-Draft June 2001

This AVP SHOULD be placed as close R- is used to represent the Diameter header as
possible.

5.5 Origin-Realm AVP responder (listening) connection. The Origin-Realm AVP (AVP Code 296) is
lack of type UTF8String. This AVP
contains a prefix indicates that the Realm of event or action is the originator same
regardless of any Diameter message and MUST
be present in all messages

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

5.6 Destination-Host AVP connection on which the event occurred.

The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity.
This AVP MUST stable states that a state machine may be present in are Closed, I-Open
and R-Open; all unsolicited agent initiated messages,
MAY be present in request messages, other states are intermediate. Note that I-Open and MUST NOT be present in Answer
messages.

The absence of the Destination-Host AVP will cause a message to be
sent to any Diameter server supporting the application within the
realm specified in Destination-Realm AVP.

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

5.7 Destination-Realm AVP

The Destination-Realm AVP (AVP Code 283)
R-Open are equivalent except for whether the initiator or responder
transport connection is of type UTF8String, and
contains used for communication.

A CER message is always sent on the realm initiating connection immediately
after the message connection request is to be routed to. successfully completed. In the case
of an election, one of the two connections will shut down. The Destination-
Realm AVP MUST NOT be present in Answer messages. Diameter Clients
insert
responder connection will survive if the realm portion Origin-Host of the User-Name AVP. local
Diameter servers
initiating a request message use the value entity is higher than that of the Origin-Realm AVP
from a previous message received from peer; the intended target host
(unless it is known a priori). When present, initiator
connection will survive if the Destination-Realm
AVP peer's Origin-Host is used to perform message routing decisions.

Request higher. All
subsequent messages whose ABNF does not list are sent on the Destination-Realm AVP
as a mandatory AVP surviving connection. Note that

Calhoun et al. expires January 2002 [Page 57]

Internet-Draft July 2001

the results of an election on one peer are inherently non-routable messages.

This AVP SHOULD be placed as close guaranteed to be the
inverse of the results on the other.

The state machine constrains only the behavior of a Diameter header
implementation as
possible.

5.8 Routing AVPs seen by Diameter peers through events on the wire.
Any implementation that produces equivalent results is considered
compliant.

state event action next state
-----------------------------------------------------------------
Closed Start I-Snd-Conn-Req Wait-Conn-Ack
R-Conn-CER R-Accept, R-Open
Process_CER,
R-Snd-CEA

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

Wait-I-CEA I-Rcv-CEA Process-CEA I-Open
R-Conn-CER R-Accept, Wait-Returns
Process_CER,
Elect
I-Peer-Disc I-Disc Closed
I-Rcv-Non-CEA Error Closed
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
R-Conn-CER R-Reject Wait-Conn-Ack/
Elect
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
R-Conn-CER R-Reject Wait-Returns
Timeout Error Closed

R-Open Send-Message R-Snd-Message R-Open
R-Rcv-Message Process R-Open
WatchDog-Timer R-Snd-DWR R-Open
R-Rcv-DWR Process-DWR, R-Open

Calhoun et al. expires December 2001 January 2002 [Page 46] 58]

Internet-Draft June July 2001

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

R-Snd-DWA
R-Rcv-DWA Process-DWA R-Open
R-Conn-CER R-Reject R-Open
Stop R-Disc Closed
R-Peer-Disc R-Disc Closed
R-Rcv-CER Error Closed
R-Rcv-CEA Error Closed

I-Open Send-Message I-Snd-Message I-Open
I-Rcv-Message Process I-Open
WatchDog-Timer I-Snd-DWR I-Open
I-Rcv-DWR Process-DWR, I-Open
I-Snd-DWA
I-Rcv-DWA Process-DWA I-Open
R-Conn-CER R-Reject I-Open
Stop I-Disc Closed
I-Peer-Disc I-Disc Closed
I-Rcv-CER Error Closed
I-Rcv-CEA Error Closed

5.6.1 Incoming connections

When a connection request is received from a Diameter CMS
Security application [11].

5.8.1 Route-Record AVP

The Route-Record AVP (AVP Code 282) peer, it is of type DiameterIdentity. The
identity added in this AVP MUST be the same as the one sent
not, in the
Origin-Host of general case, possible to know the Capabilities-Exchange-Request message.

5.8.2 Proxy-Info AVP

The Proxy-Info AVP (AVP Code 284) is identity of type Grouped. The Grouped
Data field has the following ABNF grammar:

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

5.8.3 Proxy-Host AVP

The Proxy-Host AVP (AVP Code 280) that peer
until a CER is of type DiameterIdentity. This
AVP contains received from it. This is because the identity of the a
Diameter peer is determined by host that added and port; and the Proxy-Info AVP.

5.8.4 Proxy-State AVP

The Proxy-State AVP (AVP Code 33) source port of
an incoming connection is arbitrary. Upon receipt of type OctetString, and
contains CER, the
identity of the connecting peer can be uniquely determined from
Origin-Host.

For this reason, a Diameter peer must employ logic separate from the
state local information, machine to receive connection requests, accept them, and MUST be treated as opaque data.

5.9 Redirect-Host AVP

The Redirect-Host AVP (AVP Code 292) await
CER. Once CER arrives on a new connection, the Origin-Host which
identifies the peer is of type DiameterIdentity.
This AVP MUST be present in Message-Reject-Answer messages used to locate the state machine associated
with that
include peer, and the Result-Code AVP set new connection and CER are passed to DIAMETER_REDIRECT_INDICATION.

Upon receiving the above, the receiving Diameter node
state machine as an R-Conn-CER event.

The logic that handles incoming connections SHOULD forward close and discard
the request directly connection if any message other than CER arrives, or if an
implementation-defined timeout occurs prior to the host identified receipt of CER.

Because handling of incoming connections up to and including receipt
of CER requires logic separate from that of any individual state
machine associated with a particular peer, it is described separately
in this AVP. The server
contained section rather than in the Redirect-Host SHOULD be used for all messages
pertaining to this session. state machine below.

Calhoun et al. expires December 2001 January 2002 [Page 47]

Internet-Draft June 2001

5.10 Redirect-Host-Usage AVP

The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated.
This AVP MAY be present 59]

Internet-Draft July 2001

5.6.2 Events

Transitions and actions in Message-Reject-Answer messages that
include the Result-Code AVP set to DIAMETER_REDIRECT_INDICATION.

When present, automaton are caused by events. In
this AVP dictates how section we will ignore the routing entry resulting from -I and -R prefix, since the MRA is to actual
event would be used. The following values are supported:

DONT_CACHE 0 identical, but would occur on one of two possible
connections.

Start The host specified in the Redirect-Host AVP Diameter application has signaled that a
connection should not be
cached. This is the default value.

ALL_SESSION 1
All messages within the same session, as defined by the same
value of initiated with the Session-ID AVP MAY be sent peer.

R-Conn-CER A new incoming connection and associated CER has
arrived.

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

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

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

Rcv-CER A CER message from the host specified
in peer was received.

Rcv-CEA A CEA message from the Redirect-Host AVP.

ALL_REALM 2
All messages destined for peer was received.

Rcv-Non-CEA A message other than CEA from the realm requested MAY be sent to peer was
received.

Peer-Disc A disconnection indication from the host specified in peer was
received.

Win-Election An election was held, and the Redirect-Host AVP.

REALM_AND_APPLICATION 3
All messages for local node was the application requested
winner.

Send-Message A message is to be sent.

Rcv-Message A message other than CER, CEA, DWR, or DWA was
received.

WatchDog-Timer The Watchdog timer expired, indicating that a DWR
message is to the realm
specified MAY be sent to the host specified peer.

Rcv-DWR A DWR message was received.

Rcv-DWA A DWA message was received.

Stop The Diameter application has signaled that a

Calhoun et al. expires January 2002 [Page 60]

Internet-Draft July 2001

connection should be terminated (e.g., on system
shutdown).

5.6.3 Actions

Actions in the Redirect-
Host AVP.

ALL_APPLICATION 4
All messages for automaton are caused by events and typically indicate
the application requested MAY be sent transmission of packets and/or an action to be taken on the
host specified in
connection. In this section we will ignore the Redirect-Host AVP.

ALL_HOST 5
All messages that I- and R- prefix,
since the actual action would be sent to identical, but would occur on one of
two possible connections.

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

Accept The incoming connection associated with the
MRA MAY be sent to R-
Conn-CER is accepted as the host specified in responder connection.

Reject The incoming connection associated with the Redirect-Host AVP.

5.11 Redirect-Max-Cache-Time AVP R-
Conn-CER is disconnected.

Process-CER The Redirect-Max-Cache-Time AVP (AVP Code 262) CER associated with the R-Conn-CER is of type Unsigned32.
This AVP MUST be present
processed.

Snd-Conn-Ack an acknowledgement is sent in Message-Reject-Answer messages response to a connect
request, confirming that
include the Result-Code AVP set transport layer
connection is open.

Snd-CER A CER message is sent to DIAMETER_REDIRECT_INDICATION, and the Redirect-Host-Usage AVP set peer.

Snd-CEA A CEA message is sent to a non-zero value.

This AVP contains the maximum number of seconds the peer and route
table entries, created as a result of peer.

Cleanup If necessary, the Redirect-Host, will be
cached. Note that once a host created due to a redirect indication connection is
no longer reachable, shutdown, and any associated peer
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-CEA A received CEA is processed.

Disc The transport layer connection is disconnected, and routing table entries
MUST be deleted.
local resources are freed.

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

Snd-Message A message is sent.

Calhoun et al. expires December 2001 January 2002 [Page 48] 61]

Internet-Draft June July 2001

6.0 Capabilities Exchange

When two Diameter peers establish a transport connection, they MUST
exchange

Snd-DWR A DWR message is sent.

Snd-DWA A DWA message is sent.

Process-DWR The DWR message is serviced.

Process-DWA The DWA message is serviced.

Process A message is serviced.

5.6.4 The Election Process

The election is performed on the Capabilities Exchange messages, as specified responder. The responder compares
the Origin-Host received in the CER sent by its peer
state machine (see section 8.0). This message allows the discovery of
a peer's identity and with its capabilities (protocol version number,
supported own
Origin-Host. If the local Diameter applications, etc.) entity's Origin-Host is higher
than the peer's, a Win-Election event is issued locally.

The receiver only issues commands comparison proceeds by considering the shorter OctetString to be
null-padded to its peers that have advertised
support for the Diameter application that defines length of the command. A
Diameter node MUST cache longer, then performing an octet by
octet unsigned comparison with the supported applications in order first octet being most
significant. Hanging octets are assumed to
ensure that unrecognized commands and/or AVPs have value 0x80, but
dimpled octets are ignored.

6.0 Diameter message processing

This section describes how Diameter requests and answers are not unnecessarily created
and processed.

6.1 Diameter request routing overview

A request is sent to towards its final destination using a peer.

A receiver combination
of a Capabilities-Exchange-Req (CER) message which does
not have any applications in common with the sender MUST return a
Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to
DIAMETER_NO_COMMON_APPLICATION, Destination-Realm and SHOULD disconnect the transport
layer connection. Note that receiving a CER or CEA from a peer
advertising itself as Destination-Host AVPs, in one of these
three combinations:
- a Relay (see section 6.1) MUST be interpreted request that is not proxiable (such as having common applications with the peer.

The CER and CEA messages CER) MUST NOT be proxied, contain
either Destination-Realm or redirected.

Since the CER/CEA messages cannot be proxied, it is still possible
that an upstream proxy receives Destination-Host AVPs.
- a message for which it has no
available peers to handle the application request that corresponds to the
Command-Code. In such instances, the Message-Reject-Answer message is
used (see Section 9.2.1) needs to inform the downstream be sent to take action
(e.g. re-routing request a home server serving a
specific realm, but not to an alternate peer).

With a specific server (such as the exception first
request of the Capabilities-Exchange-Request message, a
message series of type Request that includes the Auth-Application-Id or
Acct-Application-Id AVPs, or round-trips), MUST contain a message with an application-specific
command code, MAY only be forwarded to
Destination-Realm AVP, but MUST NOT contain a host that has explicitly
advertised support for the application (or has advertised the Relay
Application Identifier).

6.1 Application Identifiers

Each Diameter application Destination-Host
AVP.
- a request that needs to be sent to a specific home server among
those serving a given realm, MUST have an IANA assigned Application
Identifier (see section 15.3). The base protocol does not require an
application Identifier since its support is mandatory.

Application Identifiers are communicated via two separate AVPs;
Auth-Application-Id contain both the Destination-
Realm and Acct-Application-Id. Destination-Host AVPs.

The Auth-Application-Id Destination-Host AVP is used to communicate support for as described above when the authentication and

Calhoun et al. expires December 2001 January 2002 [Page 49] 62]

Internet-Draft June July 2001

authorization portion

destination of an application. The Acct-Application-Id AVP,
on the other hand, communicates support for the accounting portion request is fixed, which includes:
- Authentication requests that span multiple round trips
- A Diameter message that uses a security mechanism that makes use
of
an application.

This separation a pre-established session key shared between the source and
the final destination of AVPs allows the message.
- Server initiated messages that MUST be received by a server specific
Diameter client (e.g. access device), such as the Abort-
Session-Request message, which is used to communicate request that it is
willing a
particular user's session be terminated.

Note that an agent can forward a request to accept only accounting messages for a given application. host described in the
Destination-Host AVP only if the host in question is included in its
peer table (see section 2.6). Otherwise, the request is routed based
on the Destination-Realm only (see sections 6.1.6).

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 Destination-Realm AVP MUST be present if the message is routable.
A message that MUST NOT be relayed, proxied or redirected MUST advertise NOT
include the Relay application
identifier, while all other Diameter nodes MUST advertise locally
supported applications. Destination-Realm in its ABNF. The receiver value of the
Destination-Realm AVP MAY be extracted from the User-Name AVP, or
other application-specific methods.

When a Capabilities Exchange message advertising Relay service MUST assume that is received, the sender
supports all current and future applications.

Diameter relay and proxy agents are responsible for finding an
upstream server that supports message is processed in the application of a particular
message. following
order:
1. If none can be found, a MRA the message is returned with destined for the
Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.

6.2 Capabilities-Exchange-Request

The Capabilities-Exchange-Request (CER), indicated by local host, the Command-
Code set to 257 and procedures
listed in section 6.1.1 are followed.
2. If the Command Flags' 'R' bit set, message is sent to inform
a peer that intended for a reboot has occurred.

When Diameter peer with whom the
local host is run over SCTP [26], which allows for connections able to
span multiple interfaces, hence multiple IP addresses, directly communicate, the
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

Calhoun et al. expires December 2001 [Page 50]

Internet-Draft June 2001

<Capabilities-Exchange-Req> ::= < Diameter Header: 257, REQ >
{ 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 procedures
listed in section 6.1.2 are followed. This is known as Message
Forwarding.
3. The Capabilities-Exchange-Request (CEA), indicated by procedures listed in section 6.1.5 are followed, which is
known as Message Routing.
4. If none of the Command-
Code above are successful, an answer is returned with
the Result-Code set to 257 and DIAMETER_UNABLE_TO_DELIVER.

Note the Command Flags' 'R' bit cleared, is sent processing rules contained in
response 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.

6.1.1 Originating a CER message. Request

When Diameter is run over SCTP [26], which allows for connections creating a request, in addition to
span multiple interfaces, hence multiple IP addresses, any other procedures
described in the
Capabilities-Exchange-Answer message MUST contain one Host-IP-Address
AVP application definition for each potential IP address that MAY specific request,
the following procedures MUST be followed:
- the Command-Code should be set to the appropriate value
- the 'R' bit should be set
- the End-to-End Identifier should be set to a locally used when
transmitting Diameter messages.

Message Format

<Capabilities-Exchange-Answer> ::= < Diameter Header: 257 >
{ Result-Code }
{ 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 Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains unique

Calhoun et al. expires December 2001 January 2002 [Page 51] 63]

Internet-Draft June July 2001

the IANA "SMI Network Management Private Enterprise Codes" [2]

value
assigned
- the Origin-Host and Origin-Realm AVPs MUST be set to the vendor
appropriate values, used to identify the source of the Diameter device.

In combination with message
- the Supported-Vendor-Id AVP (section 6.8), this
MAY be used in order to know which vendor specific attributes may Destination-Host and Destination-Realm AVPs MUST be
sent set to
the peer. It is also envisioned that appropriate values as described in section 6.1.

6.1.2 Sending a Request

When sending a request, either originated locally, or as the combination result
of a forwarding or routing operation, the
Vendor-Id, Product-Name (section 6.9) and following procedures MUST
be followed:
- the Firmware-Revision
(section 6.5) AVPs MAY provide very useful debugging information.

A Vendor-Id Hop-by-Hop Identifier should be set to a locally unique
value of zero
- The message should be saved in the CER or CEA messages is reserved and
indicates that list of pending requests.

Other actions to perform on the Diameter peer message based on the particular role
the agent is playing are described in the experimental following sections.

6.1.3 Receiving Requests

A relay or concept
stage and that proxy agent MUST check for forwarding loops when receiving
requests. A loop is detected if the server finds its own identity in
a Route-Record AVP. When such an IANA Private Enterprise Number has yet to be
obtained by event occurs, the implementor.

6.5 Firmware-Revision AVP

The Firmware-Revision agent MUST answer
with the Result-Code AVP (AVP Code 267) is of type Unsigned32 and set to DIAMETER_LOOP_DETECTED.

6.1.4 Processing Local Requests

A request is
used known to inform a Diameter peer of the firmware revision of the
issuing device.

For devices that do not have a firmware revision (general purpose
computers running Diameter software modules, be for instance), the
revision local consumption when one of the Diameter software module may be reported instead.

6.6 Auth-Application-Id
following conditions occur:
- The Destination-Host AVP contains the local host's identity,
- The Auth-Application-Id Destination-Host AVP (AVP Code 258) is of type Unsigned32 and is used in order to advertise support of not present, the 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 defined in a separate Diameter
specification and have an Application ID assigned.

This Destination-Realm
AVP SHOULD be placed as close contains a realm the server is configured to process
locally, and the Diameter header as
possible.

6.7 Host-IP-Address AVP application is locally supported, or
- The Host-IP-Address Destination-Realm AVP (AVP Code 257) is of type IPAddress and not present.

When a request is locally processed, the rules in section 6.2 should
be used to inform a generate the corresponding answer.

6.1.5 Request Forwarding

Request forwarding is done using the Diameter Peer Table. The
Diameter peer table contains all of the sender's IP address. All
source addresses peers that a Diameter the local node expects is
able to use with SCTP [26]
MUST be advertised in the CER and CEA messages by including a Host-
IP-Address AVP for each address. This AVP MUST ONLY be used in the
CER and CEA messages. directly communicate with.

Calhoun et al. expires December 2001 January 2002 [Page 52] 64]

Internet-Draft June July 2001

6.8 Supported-Vendor-Id AVP

The Supported-Vendor-Id AVP (AVP Code 265)

When a request is of type Unsigned32 received, and
contains the IANA "SMI Network Management Private Enterprise Codes"
[2] value assigned to a vendor other than the device vendor. This is
used host encoded in the CER and CEA messages Destination-
Host AVP is one that is present in order to inform the peer that table, the
sender supports a subset of message SHOULD
be forwarded to the vendor-specific commands and/or AVPs
defined by peer.

6.1.6 Request Routing

Diameter request message routing is done via realms. A Diameter
message that is proxyable MUST include the vendor identified target realm in this the
Destination-Realm AVP.

6.9 Product-Name AVP The Product-Name AVP (AVP Code 269) is of type UTF8String, and
contains realm MAY be retrieved from the vendor assigned name for User-Name
AVP, which is in the product. form of a Network Access Identifier (NAI). The Product-Name
AVP SHOULD remain constant across firmware revisions for
realm portion of the same
product.

6.10 Acct-Application-Id AVP

The Acct-application-Id AVP (AVP Code 259) NAI is inserted in the Destination-Realm AVP.

Diameter agents MAY have a list of type Unsigned32 locally supported realms, and MAY
have a list of externally supported realms. When a request is used in order
received that includes a realm that is not locally supported, the
message is routed to advertise support of the Accounting portion of an
application (see Section 6.1). The Acct-Application-Id MUST also be
present in all Accounting messages that are defined peer configured in the Domain Routing Table
table (see section 2.7).

6.1.7 Redirecting requests

When a separate
Diameter specification and have an Application ID assigned.

This AVP SHOULD be placed as close redirector agent receives a request whose routing entry is set
to REDIRECT, it MUST reply with an answer message with the Diameter header as
possible.

6.11 Vendor-Specific-Application-Id AVP

The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
Grouped 'E' bit
set, while maintaining the Hop-by-Hop Identifier in the header, and is used
include the Result-Code AVP to advertise support DIAMETER_REDIRECT_INDICATION. Each of a vendor-specific
Diameter Application. Either
the Auth-Application-Id or servers associated with the Acct-
Application-Id AVP MAY be present. Both AVPs routing entry are added in separate
Redirect-Host AVP.

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

Redirector agents MAY be present if they
both contain the same value.

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

This AVP SHOULD be placed as close to certificate of the Diameter header as
possible. servers in
the Redirect-Host AVP(s). These certificates are encapsulated in a
CMS-Cert AVP Format [11].

Calhoun et al. expires December 2001 January 2002 [Page 53] 65]

Internet-Draft June July 2001

<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 nature

The receiver of the Diameter protocol, it is recommended that
transport failures be detected as soon as possible. Detecting such
failures will minimize answer message with the occurrence of messages sent to unavailable
servers, resulting in unnecessary delays, and will provide better
failover performance. The Device-Watchdog-Request 'E' bit set, and Device-
Watchdog-Answer messages, defined in this section, are used the
Result-Code AVP set to pro-
actively detect transport failures.

The watchdog behavior is controlled by DIAMETER_REDIRECT_INDICATION uses the Tw timer, which ranges
between 30 and 60 seconds. In order hop-by-
hop field in the Diameter header to avoid synchronization
behaviors identify the request in the
pending message queue (see Section 5.3) that can occur is to be redirected. If
no transport connection exists with fixed timers among distributed systems,
each time the watchdog interval new agent, one is calculated with a jitter by using created,
and the Tw value (which defaults request is sent directly to 30 seconds) it.

6.1.8 Relaying and randomly adding Proxying Requests

A relay or
subtracting proxy agent MUST append a random value drawn between 0.5 and 2 seconds.
Alternative calculations Route-Record AVP to create jitter MAY be used. These MUST be
pseudo-random all requests
forwarded. The AVP contains the identity of the peer the request was
received from.

The Hop-by-Hop identifier in the request is saved, and not cyclic.

When replaced with
a response is received, Tw locally unique value. The source of the request is reset. Receiving a watchdog from a
peer constitutes activity, also saved,
which includes the IP address, port and Tw should be reset. On sending a
message, protocol.

Relay and Proxy agents MAY include the Proxy-Info AVP in requests if
it requires access any local state information when the queue corresponding
response is empty, then Tw received. Alternatively, it MAY simply use local storage
to store state information.

The message is reset. If then forwarded to the watchdog
timer expires next hop, as identified in the
Domain Routing Table.

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

6.1.9 Relaying and Proxying Server-Initiated Requests

Server-initiated messages MUST include the queue is empty, then a watchdog packet is sent.

7.1 Device-Watchdog-Request

The Device-Watchdog-Request (DWR), indicated by the Command-Code set Source-Route AVPs, whose
contents are identical to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
traffic has been exchanged between two peers as defined Record-Route AVPs received in Section
7.0, and no requests are pending with the peer.

Message Format

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

7.2 Device-Watchdog-Answer

Calhoun et al. expires December 2001 January 2002 [Page 54] 66]

Internet-Draft June July 2001

The Device-Watchdog-Answer (DWA), indicated by the Command-Code set
to 280 and the Command Flags' 'R' bit cleared, is sent as a response
to the Device-Watchdog-Request message.

Message Format

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

7.3 Failover/Failback Procedures

from the event that a transport failure is detected with a peer, it is
necessary for all pending request messages to 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 access device for the node to maintain a pending message queue for a given peer. When an answer message is received, session, but in the reverse
order. Agents receiving requests with one or more Source-Route AVP
MUST use the corresponding
request is removed from last Source-Route AVP in the queue. The Hop-by-Hop Identifier field
MAY be used request to match determine the answer with
request's next hop.

In the queued request.

When a transport failure is detected, all messages event that the next hop encoded in the queue are
sent to an alternate agent, if possible. An example of a case where
it Source-Route is not possible for forward the message to
reachable, an alternate server is
when the message has a fixed destination, and peer MAY be used if the unavailable peer is in question had
advertised such peers via the message's final destination (see Destination-Host AVP). Such an
error requires that Alternate-Peer AVP in the agent return an MRA with CER or CEA
message.

6.2 Diameter Answer Processing

When a request is locally processed, the Result-Code AVP
set following procedures MUST be
applied to DIAMETER_UNABLE_TO_DELIVER.

It is important create the associated answer, in addition to note any
additional procedures that multiple identical request or answer MAY be received as a result of a failover. The End-to-End Identifier
field discussed in the Diameter header along with
application defining the Origin-Host AVP MUST be
used to identify duplicate messages.

As described command:

- The same Hop-by-Hop identifier in section 2.1, a connection request should be
periodically attempted with the failed peer request is used in order to re-establish
the transport connection. Once a connection has been successfully
established, messages can once again be forwarded to the peer. This
answer.
- The local host's identity is commonly referred to as failback.

8.0 Peer State Machine

Calhoun et al. expires December 2001 [Page 55]

Internet-Draft June 2001

This section contains a finite state machine, that encoded in the Origin-Host AVP.
- The Destination-Host and Destination-Realm AVPs MUST NOT be observed
by all Diameter implementations. Each Diameter node MUST follow
present in the
state machine described below when communicating answer message.
- The Result-Code AVP is added 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 its value indicating success
or failure.
- If the Session-Id is present in the request, it MUST be at most one transport connection between any two peers
over which Diameter messages may included
in the answer.
- Any Proxy-Info AVPs in the request MUST be passed. This state machine is
intended added to handle both the simple case, answer
message, in which one peer initiates
a connection the same order they were present in the request.
- The 'P' bit is set to the other, and same value as the complex case, one in which each peer
simultaneously initiates a connection to the other. In request.

6.2.1 Processing received Answers

A Diameter client or proxy MUST match the complex
case, Hop-by-Hop Identifier in an election occurs to determine which transport connection will
survive.
answer received against the list of pending requests. The
corresponding message should be removed from the list of pending
requests. It is important to note SHOULD ignore answers received that the port on which do not match a connection known
Hop-by-Hop Identifier.

6.2.2 Relaying and Proxying Answers

If the answer is initiated for a request which was proxied or relayed, the
agent MUST NOT be restore the original value of the Diameter header's Hop-
by-Hop Identifier field.

If the port Diameter listens for incoming
connections.

I- last Proxy-Info AVP in the message is used targeted to represent the initiator (connecting) connection, while local

Calhoun et al. expires January 2002 [Page 67]

Internet-Draft July 2001

Diameter server, the R- is used to represent AVP MUST be removed before the responder (listening) connection. The
lack of answer is
forwarded.

If a prefix indicates that the event relay or action is proxy agent receives an answer with a Result-Code AVP
indicating a failure, it MUST NOT modify the same
regardless contents of the connection on which the event occurred.

The stable states that a state machine may AVP. Any
additional local errors detected SHOULD be logged, but not reflected
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 CER message is always sent on the initiating connection immediately
after Result-Code AVP. If the connection request is successfully completed. In agent receives an answer message with
a Result-Code AVP indicating success, and it wishes to modify the case
of AVP
to indicate an election, one error, it MUST issue an STR on behalf of the two connections will shut down. access
device.

The
responder connection will survive if the Origin-Host of agent MUST then send the local
Diameter entity is higher than that of answer to the peer; host which it received the initiator
connection will survive if
original request from.

6.3 Hiding Network Topology

A Relay or Proxy agent routing messages outside of their
administrative domain MAY need to hide the peer's internal Diameter
topology. This is done by removing all Route-Record AVPs in a
request.

6.4 Origin-Host AVP

The Origin-Host AVP (AVP Code 264) is higher. All
subsequent messages are sent on the surviving connection. Note that
the results of an election on one peer are guaranteed to type DiameterIdentity, and
MUST be present in all Diameter messages. This AVP identifies the
inverse of
endpoint which originated the results on Diameter message, i.e. the other. access
device, home server, or broker. Relay agents MUST NOT modify this
AVP.

The state machine constrains only the behavior value of a Diameter
implementation as seen by Diameter peers through events on the wire.
Any implementation that produces equivalent results Origin-Host AVP is considered
compliant.

state event action next state
-----------------------------------------------------------------
Closed Start I-Snd-Conn-Req Wait-Conn-Ack
R-Conn-CER R-Accept, R-Open
Process_CER,

Calhoun et al. expires December 2001 [Page 56]

Internet-Draft June 2001

R-Snd-CEA

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

Wait-I-CEA I-Rcv-CEA Process-CEA I-Open
R-Conn-CER R-Accept, Wait-Returns
Process_CER,
Elect
I-Peer-Disc I-Disc Closed
I-Rcv-Non-CEA Error Closed
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
R-Conn-CER R-Reject Wait-Conn-Ack/
Elect
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
R-Conn-CER R-Reject Wait-Returns
Timeout Error Closed

R-Open Send-Message R-Snd-Message R-Open
R-Rcv-Message Process R-Open
WatchDog-Timer R-Snd-DWR R-Open
R-Rcv-DWR Process-DWR, R-Open
R-Snd-DWA
R-Rcv-DWA Process-DWA R-Open
R-Conn-CER R-Reject R-Open
Stop R-Disc Closed
R-Peer-Disc R-Disc Closed
R-Rcv-CER Error Closed
R-Rcv-CEA Error Closed

Note that the Origin-Host AVP may resolve to more than one address as
the Diameter peer may support more than one address.

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

6.5 Origin-Realm AVP

The Origin-Realm AVP (AVP Code 296) is of type UTF8String. This AVP
contains the Realm of the originator of any Diameter message and MUST
be present in all messages

This AVP SHOULD be placed as close to the Diameter header as

Calhoun et al. expires December 2001 January 2002 [Page 57] 68]

Internet-Draft June July 2001

R-Conn-CER R-Reject I-Open
Stop I-Disc Closed
I-Peer-Disc I-Disc Closed
I-Rcv-CER Error Closed
I-Rcv-CEA Error Closed

8.1 Incoming connections

When a connection

possible.

6.6 Destination-Host AVP

The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity.
This AVP MUST be present in all unsolicited agent initiated messages,
MAY be present in request messages, and MUST NOT be present in Answer
messages.

The absence of the Destination-Host AVP will cause a message to be
sent to any Diameter server supporting the application within the
realm specified in Destination-Realm AVP.

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

6.7 Destination-Realm AVP

The Destination-Realm AVP (AVP Code 283) is received of type UTF8String, and
contains the realm the message is to be routed to. The Destination-
Realm AVP MUST NOT be present in Answer messages. Diameter Clients
insert the realm portion of the User-Name AVP. Diameter servers
initiating a request message use the value of the Origin-Realm AVP
from a Diameter peer, previous message received from the intended target host
(unless it is
not, in known a priori). When present, the general case, possible Destination-Realm
AVP is used to know perform message routing decisions.

Request messages whose ABNF does not list the identity of that peer
until Destination-Realm AVP
as a CER is received from it. mandatory AVP are inherently non-routable messages.

This is because AVP SHOULD be placed as close to the identity of a Diameter peer is determined header as
possible.

6.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 host and port;
agents, and therefore MUST NOT be protected using the source port of
an incoming connection Diameter CMS
Security application [11].

6.8.1 Route-Record AVP

The Route-Record AVP (AVP Code 282) is arbitrary. Upon receipt of CER, the type DiameterIdentity. The
identity of the connecting peer can be uniquely determined from
Origin-Host.

For added in this reason, a Diameter peer must employ logic separate from AVP MUST be the
state machine to receive connection requests, accept them, and await
CER. Once CER arrives on a new connection, same as the one sent in the

Calhoun et al. expires January 2002 [Page 69]

Internet-Draft July 2001

Origin-Host which
identifies of the peer Capabilities-Exchange-Request message.

6.8.2 Proxy-Info AVP

The Proxy-Info AVP (AVP Code 284) is used to locate of type Grouped. The Grouped
Data field has the state machine associated
with following ABNF grammar:

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

6.8.3 Proxy-Host AVP

The Proxy-Host AVP (AVP Code 280) is of type DiameterIdentity. This
AVP contains the identity of the host that peer, and added the new connection Proxy-Info AVP.

6.8.4 Proxy-State AVP

The Proxy-State AVP (AVP Code 33) is of type OctetString, and CER are passed to the
contains state machine local information, and MUST be treated as an R-Conn-CER event. opaque data.

6.8.5 Source-Route AVP

The logic that handles incoming connections SHOULD close and discard
the connection if any message other than CER arrives, or if an
implementation-defined timeout occurs prior to receipt Source-Route AVP (AVP Code 286) is of CER.

Because handling type DiameterIdentity.
This AVP is used for routing decisions by agents for server-initiated
messages. The order of incoming connections up to and including receipt the Source-Route AVPs MUST be the inverse of CER requires logic separate from that
the Route-Record AVPs of any individual state
machine associated with a particular peer, it is described separately
in this section rather than in auth messages received by the state machine below.

8.2 Events

Transitions server for the
session in question.

6.9 Auth-Application-Id AVP

The Auth-Application-Id AVP (AVP Code 258) is of type Unsigned32 and actions
is used in order to advertise support of the automaton are caused by events. In
this section we will ignore 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 The Diameter an application has signaled (see Section 2.5). The Auth-
Application-Id MUST also be present in all Authentication and/or
Authorization messages that are defined in a
connection should be initiated with the peer.

R-Conn-CER A new incoming connection separate Diameter
specification and associated CER has
arrived.

Rcv-Conn-Ack A positive acknowledgement was received have an Application ID assigned.

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

Calhoun et al. expires December 2001 January 2002 [Page 58] 70]

Internet-Draft June July 2001

locally initiated transport connection.

Rcv-Conn-Nack A negative acknowledgement was received

6.10 Acct-Application-Id AVP

The Acct-application-Id AVP (AVP Code 259) is of type Unsigned32 and
is used in order to a
locally initiated transport connection.

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

Rcv-CER A CER message from advertise support of the peer was received.

Rcv-CEA A CEA message from Accounting portion of an
application (see Section 2.5). The Acct-Application-Id MUST also be
present in all Accounting messages that are defined in a separate
Diameter specification and have an Application ID assigned.

This AVP SHOULD be placed as close to the peer was received.

Rcv-Non-CEA A message other than CEA from 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 advertise support of a vendor-specific
Diameter Application. Either the peer was
received.

Peer-Disc A disconnection indication from Auth-Application-Id or the peer was
received.

Win-Election An election was held, and Acct-
Application-Id AVP MAY be present. Both AVPs MAY be present if they
both contain the local node was same value.

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

Send-Message A message is to vendor-specific application.

This AVP SHOULD be sent.

Rcv-Message A message other than CER, CEA, DWR, or DWA was
received.

WatchDog-Timer placed as close to the 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 }

6.12 Redirect-Host AVP

The Watchdog timer expired, indicating that a DWR
message Redirect-Host AVP (AVP Code 292) is to of type DiameterIdentity.
This AVP MUST be sent present if the answer message's 'E' bit is set and
the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.

Upon receiving the peer.

Rcv-DWR A DWR message was received.

Rcv-DWA A DWA message was received.

Stop The Diameter application has signaled that a
connection should be terminated (e.g., on system
shutdown).

8.3 Actions

Actions in above, the automaton are caused by events and typically indicate receiving Diameter node SHOULD forward
the transmission of packets and/or an action request directly to be taken on the
connection. In host identified in this section we will ignore the I- and R- prefix,
since AVP. The server
contained in the actual action would Redirect-Host SHOULD be identical, but would occur on one of
two possible connections.

Snd-Conn-Req A transport connection is initiated with the peer. used for all messages
pertaining to this session.

6.13 Redirect-Host-Usage AVP

Calhoun et al. expires December 2001 January 2002 [Page 59] 71]

Internet-Draft June July 2001

The incoming connection associated with Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated.
This AVP MAY be present in answer messages whose 'E' bit is set and
the R-
Conn-CER Result-Code AVP is accepted set to DIAMETER_REDIRECT_INDICATION.

When present, this AVP dictates how the routing entry resulting from
the Redirect-Host is to be used. The following values are supported:

DONT_CACHE 0
The host specified in the Redirect-Host AVP should not be
cached. This is the default value.

ALL_SESSION 1
All messages within the same session, as defined by the same
value of the Session-ID AVP MAY be sent to the responder connection.

Reject The incoming connection associated with host specified
in the R-
Conn-CER is disconnected.

Process-CER The CER associated with Redirect-Host AVP.

ALL_REALM 2
All messages destined for the R-Conn-CER is
processed.

Snd-Conn-Ack an acknowledgement is realm requested MAY be sent to
the host specified in response the Redirect-Host AVP.

REALM_AND_APPLICATION 3
All messages for the application requested to a connect
request, confirming that the transport layer
connection is open.

Snd-CER A CER message is realm
specified MAY be sent to the peer.

Snd-CEA A CEA message is host specified in the Redirect-
Host AVP.

ALL_APPLICATION 4
All messages for the application requested MAY be 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,
host specified in response the Redirect-Host AVP.

ALL_HOST 5
All messages that would be sent to an
error condition. Local resources are freed.

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 8.4 for more
information).

Snd-Message A message is sent.

Snd-DWR A DWR message is sent.

Snd-DWA A DWA message is sent.

Process-DWR The DWR message is serviced.

Process-DWA The DWA message is serviced.

Process A message is serviced.

8.4 The Election Process

The election is performed on the responder. The responder compares

Calhoun et al. expires December 2001 [Page 60]

Internet-Draft June 2001 host that generated the Origin-Host received
Redirect-Host MAY be sent to the host specified in the
Redirect-Host AVP.

6.14 Redirect-Max-Cache-Time AVP

The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32.
This AVP MUST be present in the CER sent by its peer with its own
Origin-Host. If the local Diameter entity's Origin-Host answer messages whose 'E' bit is higher
than set, the peer's, a Win-Election event
Result-Code AVP is issued locally.

The comparison proceeds by considering the shorter OctetString set to be
null-padded DIAMETER_REDIRECT_INDICATION and the
Redirect-Host-Usage AVP set to a non-zero value.

This AVP contains the length maximum number of seconds the longer, then performing an octet by
octet unsigned comparison with peer and route
table entries, created as a result of the first octet being most
significant. Hanging octets are assumed Redirect-Host, will be
cached. Note that once a host created due to have value 0x80, but
dimpled octets are ignored.

9.0 a redirect indication is
no longer reachable, any associated peer and routing table entries
MUST be deleted.

Calhoun et al. expires January 2002 [Page 72]

Internet-Draft July 2001

7.0 Error Handling

There are two different types of errors in Diameter; protocol and
applications. A protocol error is one that occurs at the base
protocol level, and MAY require per hop attention (e.g. message
routing error). Application errors, on the other hand, are generally
occur due to a problem with a function specified in a Diameter
application (e.g. user authentication, Missing AVP).

Result-Code AVP values that are used to report protocol errors MUST
only be used present in the Message-Reject-Answer command. Unlike most Diameter
commands, the Message-Reject-Answer does not have a corresponding
request. answer messages whose 'E' bit is set. When a
request message is received that causes a protocol error, the
command code an answer
message is changed to Message-Reject-Answer, returned with the 'E' bit set, 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 answer + 'E' set | Relay 2 | +--------+
|Diameter |<-+ (Unable to Forward) +---------+ |Diameter|
| | | Home |
| Relay 1 |--+ +---------+ | Server |
+---------+ | 3. Request |Diameter | +--------+
+-------------------->| | ^
| Relay 3 |-----------+
+---------+
Figure 4 7 - Example of Protocol Error causing MRA answer message

Figure 4 7 provides an example of a message forwarded upstream by a
Diameter relay. When the message is received by Relay 2, and it
detects that it cannot forward the request to the home server, an MRA
answer message is returned with the 'E' bit set and the Result-Code
AVP set to

Calhoun et al. expires December 2001 [Page 61]

Internet-Draft June 2001 DIAMETER_UNABLE_TO_DELIVER. Given that this error falls
within the protocol error category, Relay 1 would take special
action, and given the error, attempt to route the message through its
alternate Relay 3.

+---------+ 1. Request +---------+ 2. Request +---------+
| Access |------------>|Diameter |------------>|Diameter |
| | | | | Home |
| Device |<------------| Relay |<------------| Server |
+---------+ 4. Answer +---------+ 3. Answer +---------+
(Missing AVP) (Missing AVP)
Figure 5 8 - Example of Application Error Answer message

Figure 5 8 provides an example of a Diameter message that caused an

Calhoun et al. expires January 2002 [Page 73]

Internet-Draft July 2001

application error. When application errors occur, the Diameter entity
reporting the error clears the 'R' bit in the Command Flags, and adds
the Result-Code AVP with the proper value. Application errors do not
require any proxy or relay agent involvement, and therefore the
message would be forwarded back to the originator of the request.

There are certain Result-Code AVP application errors that require
additional AVPs to be present in the answer. In these cases, the
Diameter node that sets the Result-Code AVP to indicate the error
MUST add the AVPs. Examples are:

- An unrecognized AVP is received with the 'M' bit (Mandatory bit)
set, causes an answer to be sent with the Result-Code AVP set to
DIAMETER_AVP_UNSUPPORTED, and the Failed-AVP AVP containing the
offending AVP.
- An AVP that is received with an unrecognized value causes an
answer to be returned with the Result-Code AVP set to
DIAMETER_INVALID_AVP_VALUE, with the Failed-AVP AVP containing
the AVP causing the error.
- A command is received with an AVP that is ommitted, omitted, yet is
mandatory according to the command's ABNF. The receiver issues
an answer with the Result-Code set to DIAMETER_MISSING_AVP, and
creates an AVP with the AVP Code and other fields set to the
missing AVP's. The created AVP is then added to the Failed-AVP
AVP.

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

9.1

7.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

Calhoun et al. expires December 2001 [Page 62]

Internet-Draft June 2001
whether an error occurred. All Diameter answer messages MUST include
one Result-Code AVP. A non-successful Result-Code AVP (one containing
a non 2xxx value) MUST include the Error-Reporting-Host AVP if the
host setting the Result-Code AVP is different from the identity
encoded in the Origin-Host AVP.

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

Calhoun et al. expires January 2002 [Page 74]

Internet-Draft July 2001

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

9.1.1

7.1.1 Informational

Errors that fall within this category are used to inform the
requester that a request could not be satisfied, and additional
action is required on its part before access is granted.

DIAMETER_MULTI_ROUND_AUTH 1001
This informational error is returned by a Diameter server to
inform the access device that the authentication mechanism
being used required multiple round trip, and a subsequent
request needs to be issued in order for access to be granted.

9.1.2

7.1.2 Success

Errors that fall within the Success category are used to inform a
peer that a request has been successfully completed.

DIAMETER_SUCCESS 2001
The Request was successfully completed.

DIAMETER_LIMITED_SUCCESS 2002
When returned, the request was successfully completed, but
additional processing is required by the application in order
to provide service to the user.

9.1.3 Protocol Errors

Calhoun et al. expires December 2001 [Page 63]

Internet-Draft June 2001 service to the user.

7.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 in
the Message-Rejected-Answer message, therefore a Diameter entity that
wishes to return an error in this category MUST change the command
code to Message-Rejected-Answer message.
answer messages whose 'E' bit is set.

DIAMETER_INVALID_ROUTE_RECORD 3001
The last Route-Record AVP in the message is not set to the
identity of the sender of the message. See Section 11.0 9.0 for more
information.

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

DIAMETER_UNABLE_TO_DELIVER 3003

Calhoun et al. expires January 2002 [Page 75]

Internet-Draft July 2001

The realm requested is recognized, but no host within the realm
was available to process the request. This event occurs if no
Diameter server supporting the requested application is
reachable within the intended realm.

DIAMETER_REALM_NOT_SERVED 3004
The intended realm of the request is not recognized.

DIAMETER_TOO_BUSY 3005
When returned, a Diameter node SHOULD attempt to send the
message to an alternate peer. This error MUST only be used when
a specific server is requested, and it cannot provide the
requested service.

DIAMETER_INVALID_CMS_DATA 3006
The Request did not contain a 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 sent to an alternate
peer, if one is available, but the peer reporting the error has
identified a configuration problem.

DIAMETER_END_2_END_SECURITY

DIAMETER_CMS_SECURITY 3008
A proxy has detected that end-to-end CMS security has been applied to
portions of the Diameter message, and the proxy does not allow
this security mode since it needs to alter the message by
applying some local policies.

DIAMETER_REDIRECT_INDICATION 3009
A redirector has determined that the request could not be
satisfied locally and the initiator of the request should
direct the request directly to the server, whose contact

Calhoun et al. expires December 2001 [Page 64]

Internet-Draft June 2001
information has been added to the response. When set, the
Redirect-Host AVP MUST be present.

9.1.4

DIAMETER_APPLICATION_UNSUPPORTED 3010
A request was sent for an application that is not supported.

DIAMETER_INVALID_HDR_BITS 3011
A request was received whose bits in the Diameter header were
either set to an invalid combination, or to a value that is
inconsistent with the command code's definition.

7.1.4 Transient Failures

Errors that fall within the transient failures category are used to

Calhoun et al. expires January 2002 [Page 76]

Internet-Draft July 2001

inform a peer that the request could not be satisfied at the time it
was received, but MAY be able to satisfy the request in the future.

DIAMETER_AUTHENTICATION_REJECTED 4001
The authentication process for the user failed, most likely due
to an invalid password used by the user. Further attempts MUST
only be tried after prompting the user for a new password.

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

9.1.5

7.1.5 Permanent Failures

Errors that fall within the permanent failures category are used to
inform the peer that the request failed, and should not be attempted
again.

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

DIAMETER_AVP_UNSUPPORTED 5002
The peer received a message that contained an AVP that is not
recognized or supported and was marked with the Mandatory bit.
A Diameter message with this error MUST contain one or more
Failed-AVP AVP containing the AVPs that caused the failure.

DIAMETER_UNKNOWN_SESSION_ID 5003
The request contained an unknown Session-Id.

DIAMETER_AUTHORIZATION_REJECTED 5004
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

Calhoun et al. expires December 2001 [Page 65]

Internet-Draft June 2001
the offending AVPs within a Failed-AVP AVP.

DIAMETER_MISSING_AVP 5006
The request did not contain an AVP that is required by the
Command Code definition. If this value is sent in the Result-
Code AVP, a Failed-AVP AVP SHOULD be included in the message.
The Failed-AVP AVP MUST contain an example of the missing AVP

Calhoun et al. expires January 2002 [Page 77]

Internet-Draft July 2001

complete with the Vendor-Id if applicable. The value field of
the missing AVP should be of correct minimum length and contain
zeroes.

DIAMETER_RESOURCES_EXCEEDED 5007
A request was received that cannot be authorized because the
user has already expended allowed resources. An example of this
error condition is a user that is restricted to one dial-up PPP
port, attempts to establish a second PPP connection.

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

DIAMETER_AVP_NOT_ALLOWED 5009
A message was received with an AVP that MUST NOT be present.
The Failed-AVP AVP MUST be included and contain a copy of the
offending AVP.

DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010
A message was received that included an AVP that appeared more
often than permitted in the message definition. The Failed-AVP
AVP MUST be included and contain a copy of the first instance
of the offending AVP that exceeded the maximum number of
occurrences

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

DIAMETER_NO_COMMON_APPLICATION 5012
This error is returned when a CEA message is received, and
there are no common applications supported between the peer.

DIAMETER_UNSUPPORTED_VERSION 5013
This error is returned when a CEA message is request was received, and the
Diameter message whose
version number is unsupported.

DIAMETER_UNABLE_TO_COMPLY 5014

Calhoun et al. expires December 2001 [Page 66]

Internet-Draft June 2001
This error is returned when a request is rejected for
unspecified reasons.

DIAMETER_INVALID_BIT_IN_HEADER 5015
This error is returned when an unrecognized bit in the Diameter
header is set to one (1).

Calhoun et al. expires January 2002 [Page 78]

Internet-Draft July 2001

DIAMETER_INVALID_AVP_LENGTH 5016
The request contained an AVP with an invalid length. A Diameter
message indicating this error MUST include the offending AVPs
within a Failed-AVP AVP.

DIAMETER_INVALID_MESSAGE_LENGTH 5017
This error is returned when a request is received with an
invalid message length.

9.2 Message-Reject-Answer

The Message-Reject-Answer (MRA), indicated by the Command-Code set to
282, and the Command Flags' 'R' bit cleared, is sent in response to a
request that has caused a protocol error.

Although the command code is different from the one found in the
request, the same procedures used in issuing an answer message is
followed. The Result-Code AVP MUST be present, and include a value in
the "Protocol Error" category.

Proxies receiving received with an MRA
invalid message MAY attempt to rectify length.

7.2 Error Bit

The 'E' (Error Bit) in the Diameter header is set when the request
caused a protocol-related error
reported, if possible. In (see section 7.1.3). When set, the event that no proxy is able
answer message will not conform to correct the problem, ABNF specification for the MRA
command, and will be returned instead conform to the originator of the
request message. following ABNF:

Message Format

<Message-Reject-Answer>

<answer-message> ::= < Diameter Header: 282 code, ERR >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
{ Destination-Host }
[ Origin-State-Id ]
[ Error-Reporting-Host ]
* [ AVP ]

9.3

Note that the code used in the header is the same that the one found
in the request message, but with the 'R' bit cleared and the 'E' bit
set.

7.3 Error-Message AVP

Calhoun et al. expires December 2001 [Page 67]

Internet-Draft June 2001

The Error-Message AVP (AVP Code 281) is of type UTF8String. 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

7.4 Error-Reporting-Host AVP

The Error-Reporting-Host AVP (AVP Code 294) is of type
DiameterIdentity. This AVP contains the identity of the Diameter
host that sent the Result-Code AVP to a value other than 2001
(Success), only if the host setting the Result-Code is different from

Calhoun et al. expires January 2002 [Page 79]

Internet-Draft July 2001

the one encoded in the Origin-Host AVP. This AVP is intended to be
used for troubleshooting purposes, and MUST be set when the Result-
Code AVP indicates a failure.

9.5

7.5 Failed-AVP AVP

The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
debugging information in cases where a 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.

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), tables in section 10.0), or the presence of two or
more occurrences of an AVP which table 14.1 restricts is restricted to 0, 1, or 0-1
occurrences.

A Diameter message MAY contain one Failed-AVP AVP, containing the
entire AVP that could not be processed successfully. If the failure
reason is omission of a required AVP, an AVP with the missing AVP
code, the missing vendor id, and a zero filled payload of the minimum
required length for the ommitted omitted AVP will be added.

AVP Format

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

10.0

8.0 Diameter User Sessions

Diameter can provide two different type of services to applications.
The first involves authentication and authorization, and can

Calhoun et al. expires December 2001 [Page 68]

Internet-Draft June 2001
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 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 AVP, which is used
in subsequent messages (e.g. subsequent authorization, accounting,
etc) relating to the user's session. The Session-Id AVP is a means
for the client and servers to correlate a Diameter message with a
user session.

Calhoun et al. expires January 2002 [Page 80]

Internet-Draft July 2001

When a Diameter server authorizes a user to use network resources, resources for
a finite amount of time, and it
SHOULD is willing to extend the
authorization via a future request, it MUST add the Authorization-Lifetime Authorization-
Lifetime AVP to the answer message. The Authorization-Lifetime AVP
defines the maximum amount number of time seconds a user MAY make use of the
resources before another authorization request is
to be transmitted to expected by the
server. If The Auth-Grace-Period AVP contains the server does not receive
another authorization request before number of seconds
following the timeout occurs, it SHOULD expiration of the Authorization-Lifetime, after which
the server will release any an state information related to the user's
session. Note that if payment for services is expected by the serving
realm from the user's home realm, the Authorization-Lifetime AVP AVP,
combined with the Auth-Grace-Period AVP, implies how long the Diameter
server maximum length
the session the home realm is willing to pay for be fiscally responsible for.
Services provided past the expiration of the Authorization-Lifetime
and Auth-Grace-Perioc AVPs is the responsibility of the services rendered, therefore a
Diameter client SHOULD NOT expect payment for access
device. Of course, the actual cost of services rendered past is clearly
outside the session expiration time. scope of the protocol.

An access device MAY include an Authorization-Lifetime AVP with that does not expect to send a
value of zero re-authorization or a
session termination request to inform the Diameter server that MAY include the authorization
requested will only occur once, and no further auth messages are to
be sent Auth-
Session-State AVP with this particular session identifier. The Diameter server
MAY accept the value set to NO_STATE_MAINTAINED as a hint from the access device, or it MAY override the
Authorization-Lifetime in
to the answer message with a non-zero value.
By accepting an Authorization-Lifetime with a zero value, server. If the
Diameter server accepts the hint, it agrees that it will not receive a indication of since
no session termination message will be received once service to the
user is terminated, and
therefore it cannot maintain state for the session. If the
answer message from the server contains a different value in the
Auth-Session-State AVP (or the default value if the AVP is absent),
the access device MUST follow the server's directives. Note that a zero
Authorization-Lifetime the
value NO_STATE_MAINTAINED MUST NOT be used set in subsequent re-
authorization messages. requests and answers.

The base protocol does not include any authorization request
messages, since these are largely application-specific and are
defined in a Diameter application document. However, the base
protocol does define a 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 an application, the
Session-Id is still used to identify user sessions. However, the

Calhoun et al. expires December 2001 [Page 69]

Internet-Draft June 2001
session termination messages are not used, since a session is
signaled as being terminated by issuing an accounting stop message.

10.1

8.1 Authorization Session State Machine

This section contains a finite state machine, representing the life
cycle of Diameter sessions, and MUST be observed by all Diameter

Calhoun et al. expires January 2002 [Page 81]

Internet-Draft July 2001

implementations that makes use of the 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).

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 answer

Pending Successful Service-Specific Grant Open
Authorization answer Access
received with non-zero
Authorization-Lifetime default
Auth-Session-State value

Pending Successful Service-Specific Grant Active
Authorization answer Access
received with zero
Authorization-Lifetime Auth-Session-
State set to
NO_SESSION_MAINTAINED

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
expires on access device service
specific
auth req

Calhoun et al. expires December 2001 [Page 70]

Internet-Draft June 2001

Open Successful Service-Specific Extend Open
Authorization answer Access
received

Open Accounting message sent or process Open
received

Calhoun et al. expires January 2002 [Page 82]

Internet-Draft July 2001

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

Open Session-Timeout Expires on send STR Discon
Access Device

Open SKR ASR Received send SKA, ASA, Discon
STR

Open Session-Timeout or Authorization-Lifetime (and Cleanup Discon
Authorization-Lifetime
Auth-Grace-Period) expires
on home AAA server.

Open Session-Timeout expires on Cleanup Discon
home server

Open SKA ASA Received Cleanup Closed

Discon SKR ASR Received ignore Discon

Discon STR Received Send STA Closed

Discon STA Received Discon. Closed
user/device

Active Service to user is terminated Cleanup Closed

Closed Transition to state Cleanup

When the Cleanup action is invoked, the Diameter node MAY attempt to
release all resources for the particular session. Any event not
listed above MUST be considered as an error condition, and an answer,
if applicable, MUST be returned to the originator of the message.

10.2

8.2 Accounting Session State Machine

For applications that only require accounting services, the following
state machine MUST be supported.

Calhoun et al. expires December 2001 January 2002 [Page 71] 83]

Internet-Draft June July 2001

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

8.3 Server-Initiated Re-Auth

A Diameter server may initiate a re-authentication and/or re-
authorization service for a particular session by issuing a Re-Auth-
Request (RAR).

For example, for pre-paid services, the Diameter server that
originally authorized a session may need some confirmation that the
user is still using the services.

An access device that receives a RAR message with Session-Id equal to
a currently active session MUST initiate a re-auth towards the user,
if the service supports this particular feature. Each Diameter
application MUST state whether service-initiated re-auth is
supported, since some applications do not allow for access devices to
prompt the user for re-auth.

Calhoun et al. expires December 2001 January 2002 [Page 72] 84]

Internet-Draft June July 2001

10.3.1

8.3.1 Re-Auth-Request

The Re-Auth-Request (RAR), indicated by the Command-Code set to 258
and the message flags' 'R' bit set, may be sent by any server to the
access device that is providing session service, to request that the
user be re-authenticated and/or re-authorized.

Message Format

<Re-Auth-Request> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Re-Auth-Request-Type }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

10.3.2
* [ Source-Route ]

8.3.2 Re-Auth-Answer

The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258
and the message flags' 'R' bit clear, is sent in response to the RAR.
The Result-Code AVP MUST be present, and indicates the disposition of
the request.

A successful RAA message MUST be followed by an application-specific
authentication and/or authorization message.

Message Format

<Re-Auth-Answer> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

10.4

8.4 Session Termination

Calhoun et al. expires January 2002 [Page 85]

Internet-Draft July 2001

It is necessary for a Diameter server that authorized a session to be

Calhoun et al. expires December 2001 [Page 73]

Internet-Draft June 2001
notified when that session is no longer active, both for tracking
purposes as well as to allow stateful agents to release any resources
that they may have provided for the user's session.

When a user session that required Diameter authorization terminates,
the access device that provided the service MUST issue a Session-
Termination- Request (STR) message to the Diameter server that
authorized the service, to notify it that the session is no longer
active. An STR MUST be issued when a user 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 was
authorized but never actually started. This could occur, for example,
due to a sudden resource shortage in the 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
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 result from success to
failure, prior to forwarding the message to the access device. A
proxy that causes an authorized session not to be started MUST issue
an STR to the Diameter server that authorized the session, since the
access device has no way of knowing that the session had been
authorized.

A Diameter server that receives an STR message MUST clean up
resources (e.g., session state) associated with the Session-Id
specified in the STR, and return a Session-Termination-Answer.

A Diameter server also MUST clean up resources when the Session-
Timeout expires, or when the Authorization-Lifetime and the Auth-
Grace-Period AVPs expires without
re-authorization, receipt of a re-authorization
request, regardless of whether an STR for that session is received.
The access device is not expected to provide service beyond the
expiration of these timers; thus, expiration of either of these
timers implies that the access device may have unexpectedly shut
down.

10.4.1

8.4.1 Session-Termination-Request

The Session-Termination-Request (STR), indicated by the Command-Code
set to 275 and the Command Flags' 'R' bit set, is sent by the access

Calhoun et al. expires January 2002 [Page 86]

Internet-Draft July 2001

device to inform the Diameter Server that an authenticated and/or
authorized session is being terminated.

Calhoun et al. expires December 2001 [Page 74]

Internet-Draft June 2001

Message Format

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

10.4.2

8.4.2 Session-Termination-Answer

The Session-Termination-Answer (STA), indicated by the Command- Code
set to 275 and the message flags' 'R' bit clear, is sent by the
Diameter Server to acknowledge the notification that the session has
been terminated. The Result-Code AVP MUST be present, and MAY contain
an indication that an error occurred while servicing the STR.

Upon sending or receipt of the STA, the Diameter Server MUST release
all resources for the session indicated by the Session-Id AVP. Any
intermediate server in the Proxy-Chain MAY also release any
resources, if necessary.

Message Format

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

10.5

8.5 Aborting a Session

Calhoun et al. expires January 2002 [Page 87]

Internet-Draft July 2001

A Diameter server may request that the access device stop providing
service for a particular session by issuing an Abort-Session-Request

Calhoun et al. expires December 2001 [Page 75]

Internet-Draft June 2001
(ASR).

For example, the Diameter server that originally authorized the
session may be required to cause that session to be stopped for
credit or other reasons that were not anticipated when the session
was first authorized. Or, an operator may maintain a management
server for the purpose of issuing ASRs to administratively remove
users from the network.

An access device that receives an ASR with Session-ID equal to a
currently active session MAY stop the session. Whether the access
device stops the session or not is implementation- and/or
configuration- dependent. For example, an access device may honor
ASRs from certain agents only. In any case, the access device MUST
respond with an Abort-Session-Answer, including a Result-Code AVP to
indicate what action it took.

Note that if the access device does stop the session upon receipt of
an ASR, it issues an STR to the authorizing server (which may or may
not be the agent issuing the ASR) just as it would if the session
were terminated for any other reason.

10.5.1

8.5.1 Abort-Session-Request

The Abort-Session-Request (ASR), indicated by the Command-Code set to
274 and the message flags' 'R' bit set, may be sent by any server to
the access device that is providing session service, to request that
the session identified by the Session-Id be stopped.

Message Format

<Abort-Session-Request> ::= < Diameter Header: 274, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

10.5.2

8.5.2 Abort-Session-Answer

Calhoun et al. expires January 2002 [Page 88]

Internet-Draft July 2001

The Abort-Session-Answer (ASA), indicated by the Command-Code set to
274 and the message flags' 'R' bit clear, is sent in response to the

Calhoun et al. expires December 2001 [Page 76]

Internet-Draft June 2001
ASR. The Result-Code AVP MUST be present, and indicates the
disposition of the request.

If the session identified by Session-Id in the ASR was successfully
terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is
not currently active, Result-Code is set to
DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the
session for any other reason, Result-Code is set to
DIAMETER_UNABLE_TO_COMPLY.

Message Format

<Abort-Session-Answer> ::= < Diameter Header: 274, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

10.6

8.6 Inferring Session Termination from Origin-State-Id

Origin-State-Id is used to 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 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 which it communicates via proxy to make
such a determination. However, a server that is not directly
connected with the access device will not discover that the access
device has been restarted unless and until it receives a new request
from the access device. Thus, use of this mechanism across proxies is
opportunistic rather than reliable, but useful nonetheless.

When a Diameter server receives a Origin-State-Id that is greater
than the Origin-State-Id previously received from the same issuer, it
may assume that the issuer has lost state since the previous message
and that all sessions that were active under the lower Origin-State-

Calhoun et al. expires January 2002 [Page 89]

Internet-Draft July 2001

Id have been terminated. The Diameter server MAY clean up all session
state associated with such lost sessions, and MAY also issues STRs

Calhoun et al. expires December 2001 [Page 77]

Internet-Draft June 2001
for all such lost sessions that were authorized on upstream servers,
to allow session state to be cleaned up globally.

10.7 be cleaned up globally.

8.7 Auth-Request-Type AVP

The Auth-Request-Type AVP (AVP Code 274) is of type Enumerated and is
included in application-specific auth requests to inform the peers
whether a user is to be authenticated only, authorized only or both.
Note any value other than both MAY cause RADIUS interoperability
issues. The following values are defined:

AUTHENTICATE_ONLY 1
The request being sent is for authentication only, and MUST
contain the relevant application specific authentication AVPs
that are needed by the Diameter server to authenticate the
user.

AUTHORIZE_ONLY 2
The request being sent is for authorization only, and MUST
contain the application specific authorization AVPs that are
necessary to identify the service being requested/offered.

AUTHORIZE_AUTHENTICATE 3
The request contains a request for both authentication and
authorization. The request MUST include both the relevant
application specific authentication information, and
authorization information necessary to identify the service
being requested/offered/.

8.8 Session-Id AVP

The Session-Id AVP (AVP Code 263) is of type UTF8String and is used
to identify a specific session (see section 10.0). 8.0). All messages
pertaining to a specific session MUST include only one Session-Id AVP
and the same value MUST be used throughout the life of a session.
When present, the Session-Id SHOULD appear immediately following the
Diameter Header (see section 3.0).

The Session-Id MUST 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 accounting information. The Session-Id includes a
mandatory portion and an implementation-defined portion; a
recommended format for the implementation-defined portion is outlined

Calhoun et al. expires January 2002 [Page 90]

Internet-Draft July 2001

below.

The Session-Id MUST begin with the sender's identity encoded in the
DiameterIdentity type (see section 4.4). The remainder of the
Session-Id MAY be any sequence that the client can guarantee to be
eternally unique; however, the following format is recommended,
(square brackets [] indicate an optional element):

<diameterIdentity>;<high

<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]

<high 32 bits> and <low 32 bits> are decimal representations of the
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 high 32 bits of the 64-bit value MAY be
initialized to the time, and the low 32 bits MAY be initialized to 0.
This will for practical purposes eliminate the possibility of
overlapping Session-Ids after a reboot, assuming the reboot process
takes longer than a second. Alternatively, an implementation MAY keep
track of the increasing value in non-volatile memory.

<optional value> is implementation specific but may include a modem's
device Id, a layer 2 address, timestamp, etc.

Example, in which the standard port is used and there is no optional
value:
aaa://diameter/accesspoint7.acme.com;1876543210;523
or
accesspoint7.acme.com;1876543210;523

Calhoun et al. expires December 2001 [Page 78]

Internet-Draft June 2001

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 Diameter device initiating the
session, which in most cases is done done by the client. Note that a
Session-Id MAY be used for both the authorization and accounting
commands of a given application.

8.9 Authorization-Lifetime AVP

The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
and contains the maximum number of seconds of service to be provided
to the user before the user is to be re-authenticated and/or re-
authorized. Great care should be taken when the Authorization-
Lifetime value is determined, since a low, non-zero, value could
create significant Diameter traffic, which could congest both the
network and the agents.

Calhoun et al. expires January 2002 [Page 91]

Internet-Draft July 2001

A value of zero (0) means that immediate re-auth is necessary by the
access device. This is typically used in cases where multiple
authentication methods are used, and a successful auth response with
this AVP set to one is used to signal that the next authentication
method is to be immediately initiated. The absence of this AVP, or a
value of all ones (-1) means no re-auth is expected.

If both this AVP and the Session-Timeout AVP are present in a
message, the value of the latter MUST NOT be smaller than the
Authorization-Lifetime AVP.

An Authorization-Lifetime AVP MAY be present in a re-authorization
messages, and contains the number of seconds the user is authorized
to receive service from the time the re-auth answer message is
received by the client. Note that a
Session-Id access device.

This AVP MAY be used for both provided by the authorization and accounting
commands client as a hint of the maximum
lifetime that it is willing to accept. However, the server MAY return
a given application.

10.8 Authorization-Lifetime value that is equal to, or smaller, than the one provided by the
client.

8.10 Auth-Grace-Period AVP

The Authorization-Lifetime Auth-Grace-Period AVP (AVP Code 291) 276) is of type Unsigned32 and
contains the maximum number of seconds the Diameter server will wait
following the expiration of service to the Authorization-Lifetime AVP before
cleaning up resources for the session.

This AVP MAY be provided
to by the user before client as a hint of the user maximum
lifetime that it is willing to be re-authenticated and/or re-
authorized. Great care should be taken when accept. However, the Authorization-
Lifetime value is determined, since server MAY return
a low, non-zero, value could
create significant Diameter traffic, which could congest both that is equal to, or smaller, than the
network and one provided by the agents.

If both this
client.

8.11 Auth-Session-State AVP

The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and the Session-Timeout
specifies whether state is maintained for a particular session. The
client MAY include this AVP are present in requests as a
message, hint to the server. The
following values are supported:

STATE_MAINTAINED 0
This value of is used to specify that session state is being
maintained, and the latter access device MUST NOT be smaller than issue a session
termination message when service to the
Authorization-Lifetime AVP. user is terminated.
This AVP MAY is the default value.

Calhoun et al. expires January 2002 [Page 92]

Internet-Draft July 2001

NO_STATE_MAINTAINED 1
This value is used to specify that no session termination
messages will be provided sent by the access device upon expiration of
the Authorization-Lifetime.

8.12 Re-Auth-Request-Type AVP

The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and
is included in application-specific auth answers to inform the client as a hint
of the maximum
duration that it is willing to accept. However, action expected upon expiration of the server DOES NOT
have to observe Authorization-Lifetime.
The following values are defined:

AUTHORIZE_ONLY 0
An authorization only re-auth is expected upon expiration of
the hint, and MAY return a value that Authorization-Lifetime. This is smaller than the hint. A default value of zero means that no re-authorization if the
AVP is required, not present in answer messages that include the
Authorization-Lifetime.

AUTHORIZE_AUTHENTICATE 1
An authentication and no session termination message will be sent to authorization re-auth is expected upon
expiration of the Diameter
server.

10.9 Authorization-Lifetime.

8.13 Session-Timeout AVP

The Session-Timeout AVP (AVP Code 27) [1] is of type Unsigned32 and
contains the maximum number of seconds of service to be provided to
the user before termination of the session. When both the Session-
Timeout and the Authorization-Lifetime AVPs are present in an answer
message, the former MUST be equal to or greater than the value of the
latter.

A session terminated that terminates on an access device due to the Session-Timeout expiration
of the Session-Timeout MUST NOT generate cause an STR to be issued, unless both
the access device and the home server had previously agreed that no
session termination messages would be sent (see section 8.9).

A Session-Timeout AVP MAY be present in a re-
authentication and/or re-authorization. re-authorization messages,
and contains the number of seconds from the beginning of the re-auth.

A value of zero, or the absence of this AVP, means that this session
has an unlimited number of seconds before termination.

This AVP MAY be provided by the client as a hint of the maximum
duration
timeout that it is willing to accept. However, the server DOES NOT
have to observe the hint, and MAY return
a value that is smaller equal to, or smaller, than the hint. one provided by the
client.

Calhoun et al. expires December 2001 January 2002 [Page 79] 93]

Internet-Draft June July 2001

10.10

8.14 User-Name AVP

The User-Name AVP (AVP Code 1) [1] is of type UTF8String, which
contains the User-Name, in a format consistent with the NAI
specification [8].

10.11

8.15 Termination-Cause AVP

The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and
is used to indicate the reason why a session was terminated on the
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 the
receipt of the authorization answer message.

DIAMETER_BAD_ANSWER 3
This value indicates that the authorization answer received by
the 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 receipt of a Session-Kill-
Request Abort-
Session-Request message.

DIAMETER_LINK_BROKEN 5
The communication to the user was abruptly disconnected.

10.12

8.16 Origin-State-Id AVP

The Origin-State-Id AVP (AVP Code 278), of type Unsigned32, is a
monotonically increasing value that is advanced whenever a Diameter
entity restarts with loss of previous state, for example upon reboot.
Origin-State-Id MAY be included in any Diameter message, including
CER.

A Diameter entity issuing this AVP MUST create a higher value for
this AVP each time its state is reset. A Diameter entity MAY set
Origin-State-Id to the time of startup, or it MAY use an incrementing
counter retained in non-volatile memory across restarts.

The Origin-State-Id, if present, MUST reflect the state of the entity
indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST

Calhoun et al. expires December 2001 January 2002 [Page 80] 94]

Internet-Draft June July 2001

either remove Origin-State-Id or modify it appropriately as well.

Typically, Origin-State-Id is used by an access device that always
starts up with no active sessions; that is, any session active prior
to restart will have been been lost. By including Origin-State-Id in
a message, it allows other Diameter entities to infer that sessions
associated with a lower Origin-State-Id are no longer active. If an
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 0.

10.13

8.17 Session-Binding AVP

The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY
be present in application-specific authorization answer messages. If
present, this AVP MAY inform the Diameter client that all future
application-specific re-auth messages for this session MUST be sent
to the same authorization server. This AVP MAY also specify that a
Session-Termination-Request message for this session MUST be sent to
the same authorizing server.

This field is a bit mask, and the following bits have been defined:

RE_AUTH 1
When set, future re-auth messages for this session MUST NOT
include the Destination-Host AVP. When cleared, the default
value, the Destination-Host AVP MUST be present in all re-auth
messages for this session.

STR 2
When set, the STR message for this session MUST NOT include the
Destination-Host AVP. When cleared, the default value, the
Destination-Host AVP MUST be present in the STR message for
this session.

ACCOUNTING 4
When set, all accounting messages for this session MUST NOT
include the Destination-Host AVP. When cleared, the default
value, the Destination-Host AVP MUST be present in all
accounting messages for this session.

10.14

8.18 Session-Server-Failover AVP

The Session-Server-Failover AVP (AVP Code 271) is of type Enumerated,
and MAY be present in application-specific authorization answer

Calhoun et al. expires December 2001 January 2002 [Page 81] 95]

Internet-Draft June July 2001

messages that either do not include the Session-Binding AVP or
include the Session-Binding AVP with any of the bits set to a zero
value. If present, this AVP MAY inform the Diameter client that if a
re-auth or STR message fails due to a delivery problem, the Diameter
client SHOULD issue a subsequent message without the Destination-Host
AVP. When absent, the default value is REFUSE_SERVICE.

The following values are supported:

REFUSE_SERVICE 0
If either the re-auth or the STR message delivery fails,
terminate service with the user, and do not attempt any
subsequent attempts.

TRY_AGAIN 1
If either the re-auth or the STR message delivery fails, resend
the failed message without the Destination-Host AVP present.

ALLOW_SERVICE 2
If re-auth message delivery fails, assume that re-authorization
succeeded. If STR message delivery fails, terminate the
session.

TRY_AGAIN_ALLOW_SERVICE 3
If either the re-auth or the STR message delivery fails, resend
the failed message without the Destination-Host AVP present.
If the second delivery fails for re-auth, assume re-
authorization succeeded. If the second delivery fails for STR,
terminate the session.

10.15

8.19 Multi-Round-Time-Out AVP

The Multi-Round-Time-Out AVP (AVP Code 272) is of type Unsigned32,
and SHOULD be present in application-specific authorization answer
messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH.
This AVP contains the maximum number of seconds that the access
device MUST provide the user in responding to an authentication
request.

10.16

8.20 Class AVP

The Class AVP (AVP Code 25) is of type OctetString and is used to by
Diameter servers to return state information to the access device.
When one or more Class AVPs are present in application-specific
authorization answer messages, they MUST be present in subsequent
re-authorization, session termination and accounting messages. Class

Calhoun et al. expires December 2001 January 2002 [Page 82] 96]

Internet-Draft June July 2001

AVPs found in a re-authorization answer message override the ones
found in any previous authorization answer message. Diameter server
implementations SHOULD NOT return Class AVPs that require more than
4096 bytes of storage on the Diameter client. A Diameter client that
receives Class AVPs whose size exceeds local available storage MUST
terminate the session.

11.0

9.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.

11.1

9.1 Server Directed Model

The server directed model means that the device generating the
accounting data gets information from either the authorization server
(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 Diameter. Should Batched Accounting be
required in the future, a new Diameter 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 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.

11.2

9.2 Protocol Messages

Calhoun et al. expires December 2001 January 2002 [Page 83] 97]

Internet-Draft June July 2001

A Diameter node that receives a successful authentication and/or
authorization messages from the Home AAA Server, MUST collect
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.

11.3

9.3 Application document requirements

Each Diameter 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". The 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.

11.4

9.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 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.

Calhoun et al. expires December 2001 January 2002 [Page 84] 98]

Internet-Draft June July 2001

A further application of this protocol may include AVPs to control
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.

11.5

9.5 Accounting Records

In all accounting records the Session-Id and User-Name AVPs MUST be
present. If 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
recommended, that the end-to-end authentication cover any additional
AVPs since the Data and Service Specific AVP, and associated 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

Calhoun et al. expires December 2001 January 2002 [Page 85] 99]

Internet-Draft June July 2001

on an access device for any given session.

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. 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. A particular Diameter application specification MUST
define the type of sequences that MUST be used.

11.6

9.6 Correlation of Accounting Records

The Diameter protocol's Session-Id AVP, which is globally unique (see
section 10.7), 8.8), is used during the authorization phase to identify a
particular session. Services that do not require any authorization
still use the Session-Id AVP to identify sessions.

However, there are certain applications that require multiple
accounting sub-sessions. Such applications would send messages with a
constant Session-Id AVP, but a different Accounting-Session-Id AVP.
In these cases, correlation is performed using the Session-Id.

Furthermore, there are certain applications where a user receives
service from different access devices (e.g. Mobile IP), each with
their own unique Session-Id. In such cases, the Accounting-Multi-
Session-Id AVP is used for correlation. During authorization, a
server that determines that a request is for an existing session,
SHOULD include the Accounting-Multi-Session-Id AVP, which the access
device MUST include in all subsequent accounting messages.

The Accounting-Multi-Session-Id AVP MAY include the value of the
original Session-Id. It's contents are implementation specific, but
MUST be globally unique across other Accounting-Multi-Session-Id, and
MUST NOT change during the life of a session.

A Diameter application document MUST define the exact concept of a
session that is being accounted, and MAY define the concept of a
multi-session. For instance, the NASREQ DIAMETER application treats a
single PPP connection to a Network Access Server as one session, and
a set of Multilink PPP sessions as one multi-session.

12.0

9.7 Accounting Command-Codes

This section defines new Command-Code values that MUST be supported
by all Diameter implementations that provide Accounting services.

Calhoun et al. expires December 2001 January 2002 [Page 86] 100]

Internet-Draft June July 2001

12.1

9.7.1 Accounting-Request

The Accounting-Request command, indicated by the Command-Code field
set to 271 and the 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 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 procedures described in [11].

The AVP listed below SHOULD include service specific accounting AVPs,
as described in section 11.3. 9.3.

Message Format

<Accounting-Request> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Acct-Application-Id }
{ User-Name }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
{ Accounting-Session-Id }
[ Accounting-Interim-Interval ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

12.2

9.7.2 Accounting-Answer

The Accounting-Answer command, indicated by the Command-Code field
set to 271 and the Command Flags' 'R' bit 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.

Calhoun et al. expires December 2001 January 2002 [Page 87] 101]

Internet-Draft June July 2001

The AVP listed below SHOULD include service specific accounting AVPs,
as described in section 11.3. 9.3.

Message Format

<Accounting-Answer> ::= < Diameter Header: 271, PXY >
< Session-Id >
{ Acct-Application-Id }
{ User-Name }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
{ Accounting-Session-Id }
[ Error-Reporting-Host ]
[ Accounting-Interim-Interval ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy-Info ]
* [ Route-Record ]

13.0

9.8 Accounting AVPs

This section contains AVPs that describe accounting usage information
related to a specific session.

13.1

9.8.1 Accounting-Record-Type AVP

The Accounting-Record-Type AVP (AVP Code 480) is of type Enumerated
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.

Calhoun et al. expires December 2001 January 2002 [Page 88] 102]

Internet-Draft June July 2001

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 applications. The selection of whether to use
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.

13.2

9.8.2 Accounting-Interim-Interval AVP

The Accounting-Interim-Interval AVP (AVP Code 482) is of type
Unsigned32 and is sent from the Diameter 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. 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.

Calhoun et al. expires December 2001 January 2002 [Page 89] 103]

Internet-Draft June July 2001

13.3

9.8.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
produce unique numbers is to set the value to 0 for 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.

13.4

9.8.4 Accounting-Session-Id AVP

The Accounting-Session-Id AVP (AVP Code 44) is of type UTF8String,
following the format specified in section 10.7. 8.8. 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.

13.5

9.8.5 Accounting-Multi-Session-Id AVP

The Accounting-Multi-Session-Id AVP (AVP Code 50) is of type
UTF8String, following the format specified in section 10.7. 8.8. 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 Accounting-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

10.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

Calhoun et al. expires December 2001 January 2002 [Page 90] 104]

Internet-Draft June July 2001

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.

14.1

10.1 Base Protocol Command AVP Table

The table in this section is limited to the non-accounting Command
Codes defined in this specification.
+-----------------------------------+

Calhoun et al. expires January 2002 [Page 105]

Internet-Draft July 2001

+-----------------------------------------------+
| Command-Code |
|---+---+---+---+---+---+---+---+---+
|---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|MRA|DWR|DWA|ASR|ASA|STR|STA|
------------------------------|---+---+---+---+---+---+---+---+---| |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Alternate-Peer |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Authorization-Lifetime
Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Request-Type |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Auth-Session-State |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Lifetime | | | | | | | | | | | | |
Class |0 |0 |0 |0 |0+ |0 |0 |0 |0 |0 |0+ |0+ |
Destination-Host |0-1|0 |0 |1 |1 |0-1|0 |1 |1 |1 |0 |0-1|0 |
Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Error-Message
Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0-1|0 |0 |
Error-Reporting-Host
Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
Error-Reporting-Host|0 |0 |0 |0 |0 |0 |0-1|0 |0 | |0-1|0 |0-1|0 |0-1|
Failed-AVP |0 |0+ |0+ |0 |0 |0 |0+ |0 |0 |0 |0+ |0 |0+ |
Firmware-Revision |0-1|0-1|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Host-IP-Address |1+ |1+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Multi-Round-Time-Out
Multi-Round-Time-Out|0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Origin-Host |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-Realm |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |1 |
Origin-State-Id |0-1|0-1|0 |0 |0-1|0-1|0-1|0-1|0-1|0-1|0-1|0-1|
Product-Name |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Proxy-Info |0 |0 |0 |0 |0 |0 |0+ |0+ |0+ |0+ |0+ |0+ |
Redirect-Host |0 |0 |0+ |0 |0 |0 |0 |0 |0 |
Redirect-Host-Usage |0+ |0 |0+ |0 |0+ |
Redirect-Host-Usage |0 |0 |0 |0 |0 |0 |
Redirect-Max-Cache-Time |0 |0-1|0 |0-1|0 |0-1|
Redirect-Max-Cache- |0 |0+ |0 |0 |0 |0 |0 |0 |0-1|0 |0-1|0 |0-1|
Time | | | | | | | | | | | | |
Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |0 |0 |1 |
Re-Auth-Request-Type|0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |
Route-Record |0 |0 |0 |0 |0 |0 |0+ |0 |0+ |0+ |0+ |0+ |
Session-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Session-Id |0 |0 |1 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 |
Session-Server-Failover
Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Failover | | | | | | | | | | | | |
Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Source-Route |0 |0 |0 |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 |0 |0 |0 |
Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 |
User-Name |0 |0 |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |
Vendor-Id |1 |1 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |
Vendor-Specific-Application-Id|0+
Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0+ |0 |0 |0 |0 |
Application-Id | | | |
------------------------------|---+---+---+---+---+---+---+---+---| | | | | | | | | |
--------------------|---+---+---+---+---+---+---+---+---+---+---+---|

Calhoun et al. expires December 2001 January 2002 [Page 91] 106]

Internet-Draft June July 2001

14.2

10.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.
+-----------+
| Command |
| Code |
|-----+-----+
Attribute Name | ACR | ACA |
------------------------------|-----+-----+
Accounting-Interim-Interval | 0-1 | 0-1 |
Accounting-Multi-Session-Id | 0-1 | 0-1 |
Accounting-Record-Number | 1 | 1 |
Accounting-Record-Type | 1 | 1 |
Accounting-Session-Id | 1 | 1 |
Acct-Application-Id | 1 | 1 |
Class | 0+ | 0+ |
Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 |
Error-Reporting-Host | 0 | 0+ |
Max-Time-Wait | 0+ | 0 |
Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 |
Proxy-Info | 0+ | 0+ |
Route-Record | 0+ | 0+ |
Result-Code | 0 | 1 |
Session-Id | 1 | 1 |
------------------------------|-----+-----+

15.0

11.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.

15.1

11.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.

15.1.1

11.1.1 AVP Code

the AVP Code namespace is used to identify attributes. When the

Calhoun et al. expires December 2001 January 2002 [Page 92] 107]

Internet-Draft June July 2001

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 via Specification
Required [12].

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-272, 278-284, 257-286, 291-297, 480, 482 and
485-486. See section 4.6 for the assignment of the namespace in this
specification.

15.1.2

11.1.2 AVP Flags

There are 8 bits in the AVP Flags field of the AVP header, defined in
section 4.0. This document assigns bit 8 ('V'endor Specific), bit 7
('M'andatory) and bit 6 ('P'rotected). The remaining bits should only
be assigned via a Standards Action [12].

15.2

11.2 Diameter Header

As defined in section 3.0, the Diameter header contains two fields
that require IANA namespace management; Command Code and Command
Flags.

15.2.1

11.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, 258, 271, 274-275, 280
and 282. See section 3.1 for the assignment of the namespace in this
specification.

15.2.2

11.2.2 Command Flags

There are eight bits in the Command Flags field of the Diameter
header. This document assigns bit 8 ('R'equest) and ('R'equest), bit 7 ('P'roxy). ('P'roxy) and

Calhoun et al. expires December 2001 January 2002 [Page 93] 108]

Internet-Draft June July 2001

bit 6 ('E'rror). Bits 1 through 6 5 MUST only be assigned via a
Standards Action [12].

15.3

11.3 Application Identifiers

As defined in section 6.1, 2.5, the Application Identifier is used to
identify a specific Diameter Application. All values, other than zero
(0) are available for assignment via Standards Action [12].

Vendor-Specific Application Identifiers, encoded in the Vendor-
Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to
the vendor's enterprise number, is for Private Use.

Note that the Diameter protocol is not intended to be extended for
any purpose. Any applications defined MUST ensure that they fit
within the existing framework, and that no changes to the base
protocol are required.

15.4

11.4 Result-Code AVP Values

As defined in Section 9.1, 7.1, the Result-Code AVP (AVP Code 268) defines
the values 1001, 2001-2002, 3001-3009, 3001-3011, 4001-4003 and 5001-5017.

All remaining values are available for assignment via IETF Consensus
[12].

15.5

11.5 Accounting-Record-Type AVP Values

As defined in Section 13.1, 9.8.1, the Accounting-Record-Type AVP (AVP Code
480) defines the values 1-4. All remaining values are available for
assignment via IETF Consensus [12].

15.6

11.6 Termination-Cause AVP Values

As defined in Section 10.10, 8.14, the Termination-Cause AVP (AVP Code 295)
defines the values 1-5. All remaining values are available for
assignment via IETF Consensus [12].

15.7

11.7 Redirect-Host-Usage AVP Values

As defined in Section 5.10, 6.13, the Redirect-Host-Usage AVP (AVP Code
261) defines the values 0-5. All remaining values are available for
assignment via IETF Consensus [12].

Calhoun et al. expires December 2001 January 2002 [Page 94] 109]

Internet-Draft June July 2001

15.8

11.8 Session-Server-Failover AVP Values

As defined in Section 10.14, 8.18, the Session-Server-Failover AVP (AVP Code
271) defines the values 0-3. All remaining values are available for
assignment via IETF Consensus [12].

15.9

11.9 Session-Binding AVP Values

As defined in Section 10.13, 8.17, the Session-Server-Failover Session-Binding AVP (AVP Code 270)
defines the bits 1-4. All remaining bits are available for assignment
via IETF Consensus [12].

15.10

11.10 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.

IANA should also replace "TBD" in section sections 4.4 and 5.2 with the port
number assigned in section 2.1

16.0 2.1.

11.11 Disconnect-Cause AVP Values

As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273)
defines the values 0-2. All remaining values are available for
assignment via IETF Consensus [12].

11.12 Auth-Request-Type AVP Values

As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274)
defines the values 1-3. All remaining values are available for
assignment via IETF Consensus [27].

11.13 Auth-Session-State AVP Values

As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277)
defines the values 0-1. All remaining values are available for
assignment via IETF Consensus [27].

11.14 Re-Auth-Request-Type AVP Values

Calhoun et al. expires January 2002 [Page 110]

Internet-Draft July 2001

As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code
285) defines the values 0-1. All remaining values are available for
assignment via IETF Consensus [27].

12.0 Diameter protocol related configurable parameters

This section contains the configurable parameters that are found
throughout this document:

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.

Tc timer
The Tc timer controls the frequency that transport connection
attempts are done to a peer with whom no active transport

Calhoun et al. expires December 2001 [Page 95]

Internet-Draft June 2001
connection exists. The recommended value is 30 30 seconds.

Td timer
The Td timer controls the termination of connections with peer
in the SUSPECT state. The recommended value is 5 seconds.

Ti timer
The Tw Ti timer controls the frequency the watchdog messages are
to be sent to inactive idle peers. The recommended value is 30 seconds.

17.0

Tr timer
The Tr timer controls the frequency the watchdog messages are
to be sent to peers when there are pending requests, but not
messages have been received from the peer. The recommended
value is 10 seconds.

Tw timer
The Tw timer controls the changing of a peer to the SUSPECT
state when no answer is received to a watchdog request. The
recommended value is 5 seconds.

Calhoun et al. expires January 2002 [Page 111]

Internet-Draft July 2001

13.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 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 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.

18.0

14.0 References

[1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti-
cation Dial In User Service (RADIUS)", RFC 2865, June 2000.

[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
Application", draft-ietf-aaa-diameter-nasreq-05.txt, draft-ietf-aaa-diameter-nasreq-07.txt, IETF work
in progress, June July 2001.

Calhoun et al. expires December 2001 [Page 96]

Internet-Draft June 2001

[8] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu-
ary 1999.

[10] P. Calhoun, C. Perkins, "Diameter Mobile IP Application",
draft-ietf-aaa-diameter-mobileip-05.txt,
draft-ietf-aaa-diameter-mobileip-07.txt, IETF work in progress,
June
July 2001.

Calhoun et al. expires January 2002 [Page 112]

Internet-Draft July 2001

[11] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security appli-
cation", draft-ietf-aaa-diameter-cms-sec-00.txt draft-ietf-aaa-diameter-cms-sec-01.txt (work in pro-
gress), June July 2001.

[12] Narten, Alvestrand,"Guidelines for Writing an IANA 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, M