< draft-ietf-aaa-diameter-08.txt   draft-ietf-aaa-diameter-09.txt >
AAA Working Group Pat R. Calhoun AAA Working Group Pat R. Calhoun
Internet-Draft Black Storm Networks Internet-Draft Black Storm Networks
Category: Standards Track Haseeb Akhtar Category: Standards Track Jari Arkko
<draft-ietf-aaa-diameter-08.txt> Nortel Networks <draft-ietf-aaa-diameter-09.txt> Oy LM Ericsson Ab
Jari Arkko
Oy LM Ericsson Ab
Erik Guttman Erik Guttman
Sun Microsystems, Inc. Sun Microsystems, Inc.
Allan C. Rubens
Tut Systems, Inc.
Glen Zorn Glen Zorn
Cisco Systems, Inc. Cisco Systems, Inc.
November 2001 John Loughney
Nokia
March 2002
Diameter Base Protocol Diameter Base Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. Internet-Drafts are working of Section 10 of RFC2026.
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute Internet-Drafts are working documents of the Internet Engineering
working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
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. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2001. All Rights Reserved. Copyright (C) The Internet Society 2002. All Rights Reserved.
Abstract Abstract
The Diameter base protocol is intended to provide a AAA framework for The Diameter base protocol is intended to provide an AAA framework
Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message for Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message
format, transport, error reporting and security services to be used format, transport, error reporting and security services to be used
by all Diameter applications and MUST be supported by all Diameter by all Diameter applications and MUST be supported by all Diameter
implementations. implementations.
Table of Contents Table of Contents
1.0 Introduction 1.0 Introduction
1.1 Diameter Protocol 1.1 Diameter Protocol
1.2 Requirements language 1.1.1 Differences from Radius
1.3 Terminology 1.1.2 Description of the Document Set
1.2 Approach to Extensibility
1.2.1 Defining New AVP Values
1.2.2 Creating New AVPs
1.2.3 Creating a New Authentication Application
1.2.4 Creating a new Accounting Application
1.2.5 Application Authentication Procedures
1.3 Requirements Language
1.4 Terminology
2.0 Protocol Overview 2.0 Protocol Overview
2.1 Transport 2.1 Transport
2.1.1 SCTP Guidelines 2.1.1 SCTP Guidelines
2.2 Securing Diameter Messages 2.2 Securing Diameter Messages
2.3 Diameter Protocol Extensibility 2.3 Diameter Application Compliance
2.3.1 Defining new AVP Values 2.4 Application Identifiers
2.3.2 Creating new AVPs 2.5 Peer Table
2.3.3 Creating a new Auth Applications 2.6 Realm-Based Routing Table
2.3.4 Creating a new Accounting Application 2.7 Realm-Based Routing Table
2.3.5 Application authentication procedures 2.8 Role of Diameter Agents
2.4 Diameter Application Compliance 2.8.1 Relay Agents
2.5 Application Identifiers 2.8.2 Proxy Agents
2.7 Peer Table 2.8.3 Redirect Agents
2.8 Realm-Based Routing Table 2.8.4 Translation Agents
2.9 Role of Diameter Agents
2.9.1 Relay Agents
2.9.2 Proxy Agents
2.9.3 Redirect Agents
2.9.4 Translation Agents
3.0 Diameter Header 3.0 Diameter Header
3.1 Command Code Definitions 3.1 Command Code Definitions
3.2 Command Code ABNF specification 3.2 Command Code ABNF specification
3.3 Diameter Command Naming Conventions 3.3 Diameter Command Naming Conventions
4.0 Diameter AVPs 4.0 Diameter AVPs
4.1 AVP Header 4.1 AVP Header
4.2 Optional Header Elements 4.2 Optional Header Elements
4.3 AVP Data Formats 4.3 AVP Data Formats
4.4 Derived AVP Data Formats 4.4 Derived AVP Data Formats
4.5 Grouped AVP Values 4.5 Grouped AVP Values
skipping to change at page 5, line 14 skipping to change at page 5, line 17
9.7 Accounting Command-Codes 9.7 Accounting Command-Codes
9.7.1 Accounting-Request 9.7.1 Accounting-Request
9.7.2 Accounting-Answer 9.7.2 Accounting-Answer
9.8 Accounting AVPs 9.8 Accounting AVPs
9.8.1 Accounting-Record-Type AVP 9.8.1 Accounting-Record-Type AVP
9.8.2 Accounting-Interim-Interval AVP 9.8.2 Accounting-Interim-Interval AVP
9.8.3 Accounting-Record-Number AVP 9.8.3 Accounting-Record-Number AVP
9.8.4 Accounting-RADIUS-Session-Id AVP 9.8.4 Accounting-RADIUS-Session-Id AVP
9.8.5 Accounting-Multi-Session-Id AVP 9.8.5 Accounting-Multi-Session-Id AVP
9.8.6 Accounting-Sub-Session-Id AVP 9.8.6 Accounting-Sub-Session-Id AVP
9.8.7 Accounting-Realtime-Required AVP
10.0 AVP Occurrence Table 10.0 AVP Occurrence Table
10.1 Base Protocol Command AVP Table 10.1 Base Protocol Command AVP Table
10.2 Accounting AVP Table 10.2 Accounting AVP Table
11.0 IANA Considerations 11.0 IANA Considerations
11.1 AVP Header 11.1 AVP Header
11.1.1 AVP Code 11.1.1 AVP Code
11.1.2 AVP Flags 11.1.2 AVP Flags
11.2 Diameter Header 11.2 Diameter Header
11.2.1 Command Codes 11.2.1 Command Codes
11.2.2 Message Flags 11.2.2 Message Flags
skipping to change at page 5, line 36 skipping to change at page 5, line 40
11.5 Accounting-Record-Type AVP Values 11.5 Accounting-Record-Type AVP Values
11.6 Termination-Cause AVP Values 11.6 Termination-Cause AVP Values
11.7 Redirect-Host-Usage AVP Values 11.7 Redirect-Host-Usage AVP Values
11.8 Session-Server-Failover AVP Values 11.8 Session-Server-Failover AVP Values
11.9 Session-Binding AVP Values 11.9 Session-Binding AVP Values
11.10 Diameter TCP/SCTP Port Numbers 11.10 Diameter TCP/SCTP Port Numbers
11.11 Disconnect-Cause AVP Values 11.11 Disconnect-Cause AVP Values
11.12 Auth-Request-Type AVP Values 11.12 Auth-Request-Type AVP Values
11.13 Auth-Session-State AVP Values 11.13 Auth-Session-State AVP Values
11.14 Re-Auth-Request-Type AVP Values 11.14 Re-Auth-Request-Type AVP Values
11.15 NAPTR Service Fields
12.0 Diameter protocol related configurable parameters 12.0 Diameter protocol related configurable parameters
13.0 Security Considerations 13.0 Security Considerations
13.1 IPsec Usage
13.2 TLS Usage
14.0 References 14.0 References
15.0 Acknowledgements 15.0 Acknowledgements
16.0 Authors' Addresses 16.0 Authors' Addresses
17.0 Full Copyright Statement 17.0 Full Copyright Statement
18.0 Expiration Date 18.0 Expiration Date
Appendix A. Diameter Service Template Appendix A. Diameter Service Template
Appendix B. NAPTR Example
Appendix C. Duplicate Detection
1.0 Introduction 1.0 Introduction
Historically, the RADIUS protocol has been used to provide AAA Historically, the RADIUS protocol has been used to provide AAA
services for dial-up PPP [42] and terminal server access. Over time, services for dial-up PPP [PPP] and terminal server access. Over time,
routers and network access servers (NAS) have increased in complexity routers and network access servers (NAS) have increased in complexity
and density, making the RADIUS protocol increasingly unsuitable for and density, making the RADIUS protocol increasingly unsuitable for
use in such networks. use in such networks.
The Roaming Operations Working Group (ROAMOPS) has published a set of The Roaming Operations Working Group (ROAMOPS) has published a set of
specifications [20, 43, 44] that define how a PPP user can gain specifications [ROAMCRIT, ROAMREV, PROXYCHAIN] that define how a PPP
access to the Internet without having to dial into his/her home user can gain access to the Internet without having to dial into
service provider's modem pool. This is achieved by allowing service his/her home service provider's modem pool. This is achieved by
providers to cross-authenticate their users. Effectively, a user can allowing service providers to cross-authenticate their users.
dial into any service provider's point of presence (POP) that has a Effectively, a user can dial into any service provider's point of
roaming agreement with his/her home Internet service provider (ISP), presence (POP) that has a roaming agreement with his/her home
the benefit being that the user does not have to incur a long Internet service provider (ISP), the benefit being that the user does
distance charge while traveling, which can sometimes be quite not have to incur a long distance charge while traveling, which can
expensive. sometimes be quite expensive.
Given the number of ISPs today, ROAMOPS realized that requiring each Given the number of ISPs today, ROAMOPS realized that requiring each
ISP to set up roaming agreements with all other ISPs did not scale. ISP to set up roaming agreements with all other ISPs did not scale.
Therefore, the working group defined a "broker", which acts as an Therefore, the working group defined a "broker", which acts as an
intermediate server, whose sole purpose is to set up these roaming intermediate server, whose sole purpose is to set up these roaming
agreements. A collection of ISPs and a broker is called a "roaming agreements. A collection of ISPs and a broker is called a "roaming
consortium". There are many such brokers in existence today; many consortium". There are many such brokers in existence today; many
also provide settlement services for member ISPs. also provide settlement services for member ISPs.
The Mobile-IP Working Group has recently changed its focus to inter The Mobile-IP Working Group has recently changed its focus to inter-
administrative domain mobility, which is a requirement for cellular administrative domain mobility, which is a requirement for cellular
carriers wishing to deploy IETF-based mobility protocols. The current carriers wishing to deploy IETF-based mobility protocols. The current
cellular carriers requirements [22, 23] are very similar to the cellular carriers requirements [CDMA2000REQ, MIPREQ] are very similar
ROAMOPS model, with the exception that the access protocol is Mobile- to the ROAMOPS model, with the exception that the access protocol is
IP [45] instead of PPP. Mobile-IP [MIPV4] instead of PPP.
The Diameter protocol was not designed from the ground up. Instead, The Network Access Server Requirements (NASREQ) working group has
the basic RADIUS model was retained while fixing the flaws in the focused on proving next generation Authentication, Authorization and
RADIUS protocol itself. Diameter does not share a common protocol usage Accounting for simple dial-in access and beyond; such as
data unit (PDU) with RADIUS, but does borrow sufficiently from the Virtual Private Network support, smart authentication methods, and
protocol to ease migration. roaming concerns. The Working Group has published number of
documents the requirements for NAS user authorization as well as
criteria for evaluating NAS protocols [NASCRIT].
The basic concept behind Diameter is to provide a base protocol that The basic concept behind Diameter is to provide a base protocol that
can be extended in order to provide AAA services to new access can be extended in order to provide AAA services to new access
technologies. Currently, the protocol only concerns itself with technologies. Currently, the protocol only concerns itself with
Internet access, both in the traditional PPP sense as well as taking Internet access, both in the traditional PPP sense as well as taking
into account the ROAMOPS model, and Mobile-IP. into account the ROAMOPS model, and Mobile-IP.
Although Diameter could be used to solve a wider set of AAA problems, 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 we are currently limiting the scope of the protocol in order to
ensure that the effort remains focused on satisfying the requirements ensure that the effort remains focused on satisfying the requirements
of network access. Note that a truly generic AAA protocol used by of network access. Note that a truly generic AAA protocol used by
many applications might provide functionality not provided by many applications might provide functionality not provided by
Diameter. Therefore, it is imperative that the designers of new Diameter. Therefore, it is imperative that the designers of new
applications understand their requirements before using Diameter. applications understand their requirements before using Diameter.
1.1 Diameter Protocol 1.1 Diameter Protocol
The Diameter protocol allows peers to exchange a variety of messages. The Diameter protocol allows peers to exchange a variety of messages.
The base protocol provides the following facilities: The base protocol provides the following facilities:
- Delivery of AVPs (attribute value pairs) - Delivery of AVPs (attribute value pairs)
- Capabilities negotiation, as required in [20] - Capabilities negotiation, as required in [ROAMCRIT]
- Error notification - Error notification
- Extensibility, through addition of new commands and AVPs, as - Extensibility, through addition of new commands and AVPs, as
required in [21] required in [NASCRIT]
All data delivered by the protocol is in the form of an AVP. Some of 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 these AVP values are used by the Diameter protocol itself, while
others deliver data associated with particular applications which others deliver data associated with particular applications that
employ Diameter. AVPs may be added arbitrarily to Diameter messages, employ Diameter. AVPs may be added arbitrarily to Diameter messages,
so long as the required AVPs are included and AVPs which are so long as the required AVPs are included and AVPs that are
explicitly excluded are not included. AVPs are used by base Diameter explicitly excluded are not included. AVPs are used by the base
protocol to support the following required features: Diameter protocol to support the following required features:
- Transporting of user authentication information, for the - Transporting of user authentication information, for the
purposes of enabling the Diameter server to authenticate the purposes of enabling the Diameter server to authenticate the
user. user.
- Transporting of service specific authorization information, - Transporting of service specific authorization information,
between client and servers, allowing the peers to decide whether between client and servers, allowing the peers to decide whether
a user's access request should be granted. a user's access request should be granted.
- Exchanging resource usage information, which MAY be used for - Exchanging resource usage information, which MAY be used for
accounting purposes, capacity planning, etc. accounting purposes, capacity planning, etc.
- Relaying, proxying and redirecting of Diameter messages through - Relaying, proxying and redirecting of Diameter messages through
a server hierarchy. a server hierarchy.
The Diameter base protocol provides the minimum requirements needed The Diameter base protocol provides the minimum requirements needed
for an AAA transport protocol, as required by NASREQ [21], Mobile IP for an AAA transport protocol, as required by NASREQ [NASCRIT],
[22, 23], and ROAMOPS [20]. The base protocol is not intended to be Mobile IP [CDMA2000REQ, MIPREQ], and ROAMOPS [ROAMCRIT]. The base
used by itself, and must be used with a Diameter application, such as protocol is not intended to be used by itself, and must be used with
Mobile IP [10]. The Diameter protocol was heavily inspired and builds a Diameter application, such as Mobile IP [DIAMMIP]. The Diameter
upon the tradition of the RADIUS [1] protocol. See section 2.4. for protocol was heavily inspired by and builds upon the tradition of the
more information on Diameter applications. RADIUS [RADIUS] 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 Any node can initiate a request. In that sense, Diameter is a peer-
peer protocol. In this document, a Diameter client is an access to-peer protocol. In this document, a Diameter client is an access
device that initiates a request for authentication and/or device that initiates a request for authentication and/or
authorization of a given user. A Diameter agent is a node that does authorization of a given user. A Diameter agent is a node that does
not authenticate and/or authorize messages locally, such as proxies not authenticate and/or authorize messages locally. Examples of
and relay agents. A Diameter server is one that performs agents are proxies and relay agents. A Diameter server is one that
authentication and/or authorization of the user based on some performs authentication and/or authorization of the user based on
profile. A Diameter node MAY act as an agent for certain requests some profile. A Diameter node MAY act as an agent for certain
while act as a server for others. requests while acting as a server for others.
The Diameter protocol also supports server initiated messages towards The Diameter protocol also supports server-initiated messages towards
access devices, such as a request to abort service to a particular access devices, such as a request to abort service to a particular
user. user.
1.2 Requirements language 1.1.1 Differences from Radius
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 major differences include:
- Peer-to-peer nature
- Explicit support for intermediaries
- Connection-oriented versus connectionless
- Extensibility [see section 1.2]
- Built-in failover support
- Larger attribute space
- Integrated accounting
- Mandatory bit
- Application-layer ACKs and error messages
- Unsolicited server messages
- Peer discovery
- Capabilities negotiation
1.1.2 Description of the Document Set
Currently, the Diameter specification consists of a base
specification (this document), Transport Issues [AAATRANS] and a
number of applications: Mobile IPv4 [DIAMMIP], NASREQ [NASREQ] and
CMS Security [CMS].
The Transport Issues document [AAATRANS] discusses transport layer
issues that arise with AAA protocols and recommendations on how to
overcome these issues.
The Mobile IPv4 [DIAMMIP] application defines a Diameter application
that allows a Diameter server to perform AAA functions for Mobile
IPv4 services to a mobile node.
The NASREQ [NASREQ] application defines a Diameter Application that
allows a Diameter server to be used in a PPP/SLIP Dial-Up and
Terminal Server Access environment. Consideration was given for
servers that need to perform protocol conversion between Diameter and
RADIUS.
The CMS Security [CMS] application defines how security associations
are established between two peers and how authentication, integrity,
confidentiality and non-repudiation can be achieved.
In summary, this document defines the base protocol specification for
AAA. The MIPv4 and the NASREQ documents describe applications that
use this base specification to achieve Authentication, Authorization
and Accounting. The CMS Application describes a security application
for providing secure communication in the presence of relay and peer
agents.
1.2 Approach to Extensibility
The Diameter protocol is designed to be extensible. However, it is
strongly encouraged to reuse existing mechanism before attempting any
Diameter extensions. The extensibility includes:
- Defining new AVP values.
- Creating new AVPs
- Creating new authentication applications
- Creating a new Accounting Application
- Application Authentication Procedures
1.2.1 Defining New AVP Values
New applications should attempt to reuse AVPs defined in existing
application when possible, as opposed to creating a new AVP. For AVPs
of type Enumerated, it is possible the application requires a new
value to communicate some service-specific information.
In order to allocate a new AVP value, a request MUST be sent to IANA
[47], with a detailed explanation of the value. If the new AVP value
changes an existing command code's ABNF, the IANA AVP value request
MUST include the new ABNF itself.
1.2.2 Creating New AVPs
When no existing AVP can be used appropriately to communicate some
service-specific information, a new AVP should be created. The new
AVP being defined MUST follow one of the types listed in section 4.3.
In the event that a logical grouping of AVPs is necessary, and
multiple "groups" are possible in a given command, it is highly
recommended that a Grouped AVP be used (see Section 4.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.
2.3.3 Creating New Auth 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 [ABNF] 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 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).
1.2.4 Creating New Accounting Applications
There are services that only require the use of Diameter accounting.
Since such services need to define the service specific AVPs that
must be carried in the Accounting-Request/Answer messages, but do not
need to define command codes, the rules on allocation of Accounting
Application Identifiers is different from the ones defined in section
2.3.3.
When possible, a new Diameter accounting 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 accounting application specification MUST have an IANA
assigned Application Identifier (see section 2.4).
1.2.5 Application Authentication Procedures
When possible, applications SHOULD be designed such that new
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 [EAP], SHOULD be used.
1.3 Requirements Language
In this document, the key words "MAY", "MUST", "MUST NOT", In this document, the key words "MAY", "MUST", "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [13]. interpreted as described in [KEYWORDS].
1.3 Terminology 1.4 Terminology
AAA
Authentication, Authorization and Accounting.
Accounting Accounting
The act of collecting information on resource usage for the The act of collecting information on resource usage for the
purpose of trend analysis, auditing, billing, or cost allocation. purpose of trend analysis, auditing, billing or cost allocation.
Accounting record Accounting record
A session record represents a summary of the resource consumption A session record represents a summary of the resource consumption
of a user over the entire session. Accounting gateways creating of a user over the entire session. Accounting gateways creating
the session record may do so by processing interim accounting the session record may do so by processing interim accounting
events or accounting events from several devices serving the same events or accounting events from several devices serving the same
user. user.
Authentication Authentication
The act of verifying the identity of an entity (subject). The act of verifying the identity of an entity (subject).
Authorization Authorization
The act of determining whether a requesting entity (subject) will The act of determining whether a requesting entity (subject) will
be allowed access to a resource (object). be allowed access to a resource (object).
AVP AVP
The Diameter protocol consists of a header followed by one or more The Diameter protocol consists of a header followed by one or more
Attribute-Value-Pair (AVP). The AVP includes a header and is used Attribute-Value-Pair (AVP). The AVP includes a header and is used
to encapsulation protocol-specific data (e.g. routing information) to encapsulate protocol-specific data (e.g. routing information)
as well as authentication, authorization or accounting as well as authentication, authorization or accounting
information. information.
Broker Broker
A broker is a business term commonly used in AAA infrastructures. A broker is a business term commonly used in AAA infrastructures.
A broker is either a relay, proxy or redirect agent, and MAY be A broker is either a relay, proxy or redirect agent, and MAY be
operated by roaming consortiums. operated by roaming consortiums.
Diameter Agent Diameter Agent
A Diameter Agent is a host that is providing either relay, proxy, A Diameter Agent is a host that is providing either relay, proxy,
redirect or translation services. redirect or translation services.
Diameter Client Diameter Client
A Diameter Client is a device at the edge of the network that A Diameter Client is a device at the edge of the network that
performs access control. An example of a Diameter client is a performs access control. An example of a Diameter client is a
Network Access Server (NAS) or a Foreign Agent (FA). Network Access Server (NAS) or a Foreign Agent (FA).
Diameter Node Diameter Node
A Diameter node is a host that implements the Diameter protocol, A Diameter node is a host that implements the Diameter protocol,
and acts either as a Client, Agent or Server. and acts either as a Client, Agent or Server.
Diameter Peer
A Diameter Peer is a Diameter Node to which a given Diameter Node
has a direct transport connection.
Diameter Server Diameter Server
A Diameter Server is one that handles authentication, A Diameter Server is one that handles authentication,
authorization and accounting requests for a particular realm. By authorization and accounting requests for a particular realm. By
its very nature, a Diameter Server MUST support Diameter its very nature, a Diameter Server MUST support Diameter
applications in addition to the base protocol. applications in addition to the base protocol.
Downstream Downstream
Downstream is used to identify the direction of a particular Downstream is used to identify the direction of a particular
Diameter message from the home server towards the access device. Diameter message from the home server towards the access device.
Home Realm Home Realm
A Home Realm is the administrative domain with whom the user A Home Realm is the administrative domain with which the user
maintains an account relationship. maintains an account relationship.
Home Server Home Server
See Diameter Server. See Diameter Server.
Interim accounting Interim accounting
An interim accounting message provides a snapshot of usage during An interim accounting message provides a snapshot of usage during
a user's session. It is typically implemented in order to provide 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 for partial accounting of a user's session in the event of a
device reboot or other network problem that prevents the reception device reboot or other network problem that prevents the reception
skipping to change at page 10, line 4 skipping to change at page 14, line 16
device reboot or other network problem that prevents the reception device reboot or other network problem that prevents the reception
of a session summary message or session record. of a session summary message or session record.
Local Realm Local Realm
A local realm is the administrative domain providing services to a A local realm is the administrative domain providing services to a
user. An administrative domain MAY act as a local realm for user. An administrative domain MAY act as a local realm for
certain users, while being a home realm for others. certain users, while being a home realm for others.
Multi-session Multi-session
A multi-session represents a logical linking of several sessions. A multi-session represents a logical linking of several sessions.
Multi-sessions are tracked by using the Accounting-Multi-Session- Multi-sessions are tracked by using the Accounting-Multi-Session-
Id. An example of a multi-session would be a MLP bundle. Each leg Id. An example of a multi-session would be a MLP bundle. Each leg
of the bundle would be a session while the entire bundle would be of the bundle would be a session while the entire bundle would be
a multi-session. a multi-session.
Network Access Identifier Network Access Identifier
The Network Access Identifier, or NAI [8], is used in the Diameter The Network Access Identifier, or NAI [NAI], is used in the
protocol to extract a user's identity and realm. The identity is Diameter protocol to extract a user's identity and realm. The
used to identify the user during authentication and/or identity is used to identify the user during authentication and/or
authorization, while the realm is used for message routing authorization, while the realm is used for message routing
purposes. purposes.
Proxy Proxy
In addition to forwarding requests and responses, proxies enforce In addition to forwarding requests and responses, proxies enforce
policies relating to resource usage and provisioning. This is policies relating to resource usage and provisioning. This is
typically accomplished by tracking the state of NAS devices. While typically accomplished by tracking the state of NAS devices. While
proxies typically do not respond to client Requests prior to proxies typically do not respond to client Requests prior to
receiving a Response from the server, they may originate Reject receiving a Response from the server, they may originate Reject
messages in cases where policies are violated. As a result, messages in cases where policies are violated. As a result,
proxies need to understand the semantics of the messages passing proxies need to understand the semantics of the messages passing
through them, and may not support all Diameter applications. through them, and may not support all Diameter applications.
Realm Realm
The string in the NAI that immediately follows the '@' character. The string in the NAI that immediately follows the '@' character.
NAI realm names are required to be unique, and are piggybacked on NAI realm names are required to be unique, and are piggybacked on
the administration of the DNS namespace. Diameter makes use of the the administration of the DNS namespace. Diameter makes use of the
realm, also loosely referred to as domain, to determine whether realm, also loosely referred to as domain, to determine whether
messages can be satisfied locally, or whether they must be messages can be satisfied locally, or whether they must be routed
proxied. or redirected.
Real-time Accounting Real-time Accounting
Real-time accounting involves the processing of information on Real-time accounting involves the processing of information on
resource usage within a defined time window. Time constraints are resource usage within a defined time window. Time constraints are
typically imposed in order to limit financial risk. typically imposed in order to limit financial risk.
Relay Relay
Relays forward requests and responses based on routing-related Relays forward requests and responses based on routing-related
AVPs and realm forwarding table entries. Since relays do not AVPs and realm routing table entries. Since relays do not enforce
enforce policies, they do not examine or alter non-routing AVPs. policies, they do not examine or alter non-routing AVPs. As a
As a result, relays never originate messages, do not need to result, relays never originate messages, do not need to understand
understand the semantics of messages or non-routing AVPs, and are the semantics of messages or non-routing AVPs, and are capable of
capable of handling any Diameter applications or message type. handling any Diameter application or message type. Since relays
Since relays make decisions based on information in routing AVPs make decisions based on information in routing AVPs and realm
and realm forwarding tables they do not keep state on NAS resource forwarding tables they do not keep state on NAS resource usage or
usage or conversations in progress. conversations in progress.
Redirect Agent Redirect Agent
Rather than forwarding requests and responses between clients and Rather than forwarding requests and responses between clients and
servers, redirect agents refer clients to servers and allow them servers, redirect agents refer clients to servers and allow them
to communicate directly. Since redirect agents do not sit in the to communicate directly. Since redirect agents do not sit in the
forwarding path, they do not alter any AVPs transitting between forwarding path, they do not alter any AVPs transiting between
client and server. Redirect agents do not originate messages and client and server. Redirect agents do not originate messages and
are capable of handling any message type, although they may be are capable of handling any message type, although they may be
configured only to redirect messages of certain types, while configured only to redirect messages of certain types, while
acting as Routing or Policy proxies for other types. As with acting as Routing or Policy proxies for other types. As with
Routing proxies, redirect agents do not keep state with respect to Routing proxies, redirect agents do not keep state with respect to
conversations or NAS resources. conversations or NAS resources.
Roaming Relationships Roaming Relationships
Roaming relationships include relationships between companies and Roaming relationships include relationships between companies and
ISPs, relationships among peer ISPs within a roaming association, ISPs, relationships among peer ISPs within a roaming consortium,
and relationships between an ISP and a roaming consortia. 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 Session
A session is a related progression of events devoted to a A session is a related progression of events devoted to a
particular activity. Each application SHOULD provide guidelines as particular activity. Each application SHOULD provide guidelines as
to when a session begins and ends. All Diameter packets with the to when a session begins and ends. All Diameter packets with the
same Session-Identifier are considered to be part of the same same Session-Identifier are considered to be part of the same
session. session.
Sub-session Sub-session
A sub-session represents a distinct service (e.g. QoS or data A sub-session represents a distinct service (e.g. QoS or data
skipping to change at page 12, line 4 skipping to change at page 16, line 10
Translation Agent Translation Agent
A translation agent is a stateful Diameter node that performs A translation agent is a stateful Diameter node that performs
protocol translation between Diameter and another AAA protocol. protocol translation between Diameter and another AAA protocol.
Upstream Upstream
Upstream is used to identify the direction of a particular Upstream is used to identify the direction of a particular
Diameter message from the access device towards the home server. Diameter message from the access device towards the home server.
2.0 Protocol Overview 2.0 Protocol Overview
The base Diameter protocol is never used on its own. It is always The base Diameter protocol is never used on its own. It is always
extended for a particular application. Three Diameter applications extended for a particular application. Three Diameter applications
are defined by companion documents: NASREQ [7], Mobile IP [10], CMS are defined by companion documents: NASREQ [NASREQ], Mobile IP
Security [11]. These options are introduced in this document but [DIAMMIP], CMS Security [CMS]. These applications are introduced in
specified elsewhere. Additional Diameter applications MAY be defined this document but specified elsewhere. Additional Diameter
in the future (see Section 11.3). applications MAY be defined in the future (see Section 11.3).
Diameter Clients MUST support the base protocol, which includes Diameter Clients MUST support the base protocol, which includes
accounting. In addition, they MUST fully support each Diameter accounting. In addition, they MUST fully support each Diameter
application which is needed to implement the client's service, e.g. application that is needed to implement the client's service, e.g.
NASREQ and/or Mobile IP. A Diameter Client which does not support NASREQ and/or Mobile IP. A Diameter Client that does not support both
both NASREQ and Mobile IP, MUST be referred to as "Diameter X Client" NASREQ and Mobile IP, MUST be referred to as "Diameter X Client"
where X is the application which it supports, and not a "Diameter where X is the application which it supports, and not a "Diameter
Client." Client."
Diameter Servers must support the base protocol, which includes Diameter Servers MUST support the base protocol, which includes
accounting. In addition, they MUST fully support each Diameter accounting. In addition, they MUST fully support each Diameter
application which is needed to implement the intended service, e.g. application that is needed to implement the intended service, e.g.
NASREQ and/or Mobile IP. A Diameter Server which does not support NASREQ and/or Mobile IP. A Diameter Server that does not support both
both NASREQ and Mobile IP, MUST be referred to as "Diameter X Server" NASREQ and Mobile IP, MUST be referred to as "Diameter X Server"
where X is the application which it supports, and not a "Diameter where X is the application which it supports, and not a "Diameter
Server." Server."
Diameter Relays and Redirect agents are, by definition, protocol Diameter Relays and Redirect agents are, by definition, protocol
transparent, and MUST transparently support the Diameter base transparent, and MUST transparently support the Diameter base
protocol, which includes accounting, and all Diameter applications. protocol, which includes accounting, and all Diameter applications.
Diameter Proxies MUST support the base protocol, which includes Diameter Proxies MUST support the base protocol, which includes
accounting. In addition, they MUST fully support each Diameter accounting. In addition, they MUST fully support each Diameter
application which is needed to implement proxied services, e.g. application that is needed to implement proxied services, e.g. NASREQ
NASREQ and/or Mobile IP. A Diameter Proxy which does not support also and/or Mobile IP. A Diameter Proxy which does not support also both
both NASREQ and Mobile IP, MUST be referred to as "Diameter X Proxy" NASREQ and Mobile IP, MUST be referred to as "Diameter X Proxy" where
where X is the application which it supports, and not a "Diameter X is the application which it supports, and not a "Diameter Proxy."
Proxy."
The Diameter CMS security application [11] contains two features: The Diameter CMS security application [CMS] contains two features:
1. A set of messages that allows a Diameter node to establish a 1. A set of messages that allows a Diameter node to establish a
security association, which is used to secure AVPs within a security association, which is used to secure AVPs within a
Diameter message, even though the message may traverse Diameter message, even though the message may traverse
intermediate Diameter agents. A set of AVPs are also defined to intermediate Diameter agents. A set of AVPs is also defined to
sign and encrypt AVPs, as well as to transport certificates. sign and encrypt AVPs, as well as to transport certificates.
This feature MUST be supported by Diameter server and proxy This feature MUST be supported by Diameter server and proxy
agents, SHOULD be supported by Diameter clients, and MAY be agents, SHOULD be supported by Diameter clients, and MAY be
supported by relay and redirect agents. supported by relay and redirect agents.
2. A set of messages, known as PDSR and PDSA, allows a Diameter 2. A set of messages, known as PDSR and PDSA, allows a Diameter
client to request that an agent establish a Diameter security client to request that an agent establish a Diameter security
association with a server in a specific realm. This feature association with a server in a specific realm. This feature
MUST be supported by Diameter clients and Proxy agents, and MAY MUST be supported by Diameter clients and Proxy agents, and MAY
be supported by Diameter servers, relay and redirect agents. be supported by Diameter servers, relay and redirect agents.
The base Diameter protocol concerns itself with capabilities The base Diameter protocol concerns itself with capabilities
negotiation, how messages are sent and how peers may eventually be negotiation, how messages are sent and how peers may eventually be
abandoned. The base protocol also defines certain rules which apply abandoned. The base protocol also defines certain rules that apply
to all exchanges of messages between Diameter nodes. to all exchanges of messages between Diameter nodes.
Communication between Diameter peers begins with one peer sending a Communication between Diameter peers begins with one peer sending a
message to another Diameter peer. The set of AVPs included in the message to another Diameter peer. The set of AVPs included in the
message is determined by a particular Diameter application. One AVP message is determined by a particular Diameter application. One AVP
that is included to reference a user's session is the Session-Id. that is included to reference a user's session is the Session-Id.
The initial request for authentication and/or authorization of a user The initial request for authentication and/or authorization of a user
would include the Session-Id. The Session-Id is then used in all would include the Session-Id. The Session-Id is then used in all
subsequent messages to identify the user's session (see section 8.0 subsequent messages to identify the user's session (see section 8.0
skipping to change at page 13, line 33 skipping to change at page 17, line 39
application employed. application employed.
Session state (associated with a Session-Id) MUST be freed upon Session state (associated with a Session-Id) MUST be freed upon
receipt of the Session-Termination-Request, Session-Termination- receipt of the Session-Termination-Request, Session-Termination-
Answer, expiration of authorized service time in the Session-Timeout Answer, expiration of authorized service time in the Session-Timeout
AVP, and according to rules established in a particular Diameter AVP, and according to rules established in a particular Diameter
application. application.
2.1 Transport 2.1 Transport
The base Diameter protocol is run on port TBD of both TCP [27] and The base Diameter protocol is run on port TBD of both TCP [TCP] and
SCTP [26] transport protocols (for interoperability test purposes SCTP [SCTP] transport protocols (for interoperability test purposes
port 1812 will be used until IANA assigns a port to the protocol). 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 When used with TLS [TLS], the Diameter protocol is run on port TBD of
both TCP and SCTP. both TCP and SCTP.
Diameter clients MUST support either TCP or SCTP, while agents and Diameter clients MUST support either TCP or SCTP, while agents and
servers MUST support both. Future versions of this specification MAY servers MUST support both. Future versions of this specification MAY
mandate that clients support SCTP. mandate that clients support SCTP.
A Diameter node MAY initiate connections from any source port, other A Diameter node MAY initiate connections from a source port other
than the one which they declare they accept incoming connections on, than the one that it declares it accepts incoming connections on, and
and MUST be prepared to receive connections on port TBD. A given MUST be prepared to receive connections on port TBD. A given Diameter
Diameter process MUST NOT use more than one transport connection to process MUST NOT use more than one transport connection to
communicate with a given peer, unless multiple processes exist on the communicate with a given peer, unless multiple processes exist on the
peer in which case a separate connection per process is allowed. peer in which case a separate connection per process is allowed.
When no transport connection exists with a peer, an attempt to When no transport connection exists with a peer, an attempt to
connect SHOULD be periodically attempted. This behavior is handled connect SHOULD be periodically attempted. This behavior is handled
via the Tc timer, whose recommended value is 30 seconds. There are via the Tc timer, who's recommended value is 30 seconds. There are
certain exceptions to this rule, such as when a peer has terminated certain exceptions to this rule, such as when a peer has terminated
the transport connection stating that it does not wish to the transport connection stating that it does not wish to
communicate. communicate.
When connecting to a peer, and either zero or more transports are When connecting to a peer, and either zero or more transports are
specified, SCTP SHOULD be tried first, followed by TCP. See section specified, SCTP SHOULD be tried first, followed by TCP. See section
5.2 for more information on peer discovery. 5.2 for more information on peer discovery.
Diameter implementations SHOULD be able to interpret ICMP protocol Diameter implementations SHOULD be able to interpret ICMP protocol
and port unreachable messages as explicit indications that the server port unreachable messages as explicit indications that the server is
is not reachable, in addition to interpreting ECONNREFUSED (a reset not reachable, in addition to interpreting ECONNREFUSED (a reset from
from the transport) and timed-out connection attempts. the transport) and timed-out connection attempts.
If Diameter receives data up from TCP that cannot be parsed or If Diameter receives data up from TCP that cannot be parsed or
identified as a Diameter error made by the peer, the stream is identified as a Diameter error made by the peer, the stream is
compromised and cannot be recovered. The transport connection MUST compromised and cannot be recovered. The transport connection MUST
be closed using a RESET call (graceful closure is also compromised). be closed using a RESET call (graceful closure is also compromised).
2.1.1 SCTP Guidelines 2.1.1 SCTP Guidelines
The following are guidelines for Diameter implementations that The following are guidelines for Diameter implementations that
support SCTP: support SCTP:
skipping to change at page 14, line 39 skipping to change at page 18, line 45
1. For interoperability: All Diameter nodes MUST be prepared to 1. For interoperability: All Diameter nodes MUST be prepared to
receive Diameter messages on any SCTP stream in the receive Diameter messages on any SCTP stream in the
association. association.
2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP 2. To prevent blocking: All Diameter nodes SHOULD utilize all SCTP
streams available to the association to prevent head-of-the- streams available to the association to prevent head-of-the-
line blocking. line blocking.
2.2 Securing Diameter Messages 2.2 Securing Diameter Messages
Diameter clients, such as Network Access Servers (NASes) and Mobility Diameter clients, such as Network Access Servers (NASes) and Mobility
Agents MUST support IP Security [37], and MAY support TLS [38]. Agents MUST support IP Security [SEC ARCH], and MAY support TLS
Diameter servers MUST support TLS and IPSec. Operating the Diameter [TLS]. Diameter servers MUST support TLS and IPsec. Operating the
protocol without any security mechanism is not recommended. 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
New applications should attempt to reuse AVPs defined in existing
application when possible, as opposed to creating a new AVP. For AVPs
of type Enumerated, it is possible the application requires a new
value to communicate some service-specific information.
In order to allocate a new AVP value, a request MUST be sent to IANA
[47], with a detailed explanation of the value. If the new AVP value
changes an existing command code's ABNF, the IANA AVP value request
MUST include the new ABNF itself.
2.3.2 Creating new AVPs
When no existing AVP can be used appropriately to communicate some
service-specific information, a new AVP should be created. The new
AVP being defined MUST follow one of the types listed in section 4.3.
In the event that a logical grouping of AVPs is necessary, and
multiple "groups" are possible in a given command, it is highly
recommended that a Grouped AVP be used (see Section 4.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.
2.3.3 Creating new Auth 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 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 Creating a new Accounting Application
There are services that only require the use of Diameter accounting.
Since such services need to define the service specific AVPs that
must be carried in the Accounting-Request/Answer messages, but do not
need to define command codes, the rules on allocation of Accounting
Application Identifiers is different from the ones defined in section
2.3.3.
When possible, a new Diameter accounting 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 accounting application specification MUST have an IANA
assigned Application Identifier (see section 2.4).
2.3.5 Application authentication procedures
When possible, applications SHOULD be designed such that new It is suggested that IPsec can be used primarily at the edges and in
authentication methods MAY be added without requiring changes to the intra-domain traffic, such as using pre-shared keys between a NAS a
application. This MAY require that new AVP values be assigned to local AAA proxy. This also eases the requirements on the NAS to
represent the new authentication transform, or any other scheme that support certificates. It is also suggested that inter-domain traffic
produces similar results. When possible, authentication frameworks, would primarily use TLS. See sections 13.1 and 13.2 for more details
such as Extensible Authentication Protocol [25], SHOULD be used. on IPsec and TLS usage.
2.4 Diameter Application Compliance 2.3 Diameter Application Compliance
Application Identifiers are advertised during the capabilities Application Identifiers are advertised during the capabilities
exchange phase (see section 2.5). For a given application, there are exchange phase (see section 2.5). For a given application, there are
two different ways of advertising support. First, advertising support two different ways of advertising support. First, advertising support
of the application via the Auth-Application-Id implies that the of the application via the Auth-Application-Id implies that the
sender supports all authentication and authorization command codes, sender supports all authentication and authorization command codes,
and the AVPs specified in the associated ABNFs, described in the and the AVPs specified in the associated ABNFs, described in the
specification. Second, advertising support of the application via the specification. Second, advertising support of the application via the
Acct-Application-Id implies that the sender supports the Accounting Acct-Application-Id implies that the sender supports the Accounting
command codes defined in this specification, as well as the command codes defined in this specification, as well as the
accounting AVPs defined in the application's specification. accounting AVPs defined in the application's specification.
An implementation MAY add arbitrary AVPs to any command defined in an An implementation MAY add arbitrary AVPs to any command defined in an
application, including vendor-specific AVPs. However, implementations application, including vendor-specific AVPs. Please refer to section
that add such AVPs with the Mandatory 'M' bit set are not compliant, 4.6 for details.
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 Application Identifiers 2.4 Application Identifiers
Each Diameter application MUST have an IANA assigned Application Each Diameter application MUST have an IANA assigned Application
Identifier (see section 11.3). The base protocol does not require an Identifier (see section 11.3). The base protocol does not require an
application Identifier since its support is mandatory. During the Application Identifier since its support is mandatory. During the
capabilities exchange, Diameter nodes inform their peers of locally capabilities exchange, Diameter nodes inform their peers of locally
supported applications. Furthermore, all Diameter messages contain an supported applications. Furthermore, all Diameter messages contain an
application identifier, which is used in the message forwarding Application Identifier, which is used in the message forwarding
process. process.
The following Application Identifier values are defined: The following Application Identifier values are defined:
NASREQ 1 [7] NASREQ 1 [NASREQ]
CMS Security 2 [11] CMS Security 2 [CMS]
Mobile-IP 4 [10] Mobile-IP 4 [DIAMMIP]
Relay 0xffffffff Relay 0xffffffff
Relay and redirect agents MUST advertise the Relay application Relay and redirect agents MUST advertise the Relay Application
identifier, while all other Diameter nodes MUST advertise locally Identifier, while all other Diameter nodes MUST advertise locally
supported applications. The receiver of a Capabilities Exchange supported applications. The receiver of a Capabilities Exchange
message advertising Relay service MUST assume that the sender message advertising Relay service MUST assume that the sender
supports all current and future applications. supports all current and future applications.
Diameter relay and proxy agents are responsible for finding an Diameter relay and proxy agents are responsible for finding an
upstream server that supports the application of a particular upstream server that supports the application of a particular
message. If none can be found, an error message is returned with the message. If none can be found, an error message is returned with the
Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER. Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER.
2.6 Connections vs. Sessions 2.5 Connections vs. Sessions
This section attempts to provide the reader with an understanding of This section attempts to provide the reader with an understanding of
the difference between connection and session, which are terms used the difference between connection and session, which are terms used
extensively throughout this document. extensively throughout this document.
A connection is a transport level connection between two peers, used A connection is a transport level connection between two peers, used
to send and receive Diameter messages. A session is a logical concept to send and receive Diameter messages. A session is a logical concept
at the application layer, and is shared between an access device and at the application layer, and is shared between an access device and
a server, and is identified via the Session-Id AVP a server, and is identified via the Session-Id AVP
skipping to change at page 18, line 26 skipping to change at page 20, line 37
<-----------------------------> <----------------------------->
User session x User session x
Figure 1: Diameter connections and sessions Figure 1: Diameter connections and sessions
In the example provided in figure 1, peer connection A is established In the example provided in figure 1, peer connection A is established
between the Client and its local Relay. Peer connection B is between the Client and its local Relay. Peer connection B is
established between the Relay and the Server. User session x spans established between the Relay and the Server. User session x spans
from the Client via the Relay to the Server. Each "user" of a service from the Client via the Relay to the Server. Each "user" of a service
causes an auth request to be sent, with a unique session identifier. causes an auth request to be sent, with a unique session identifier.
Once accepted by the server, both the client and the server are aware Once accepted by the server, both the client and the server are aware
of the session. It is important to note that there is no of the session. It is important to note that there is no relationship
relationship between a connection and a session, and that Diameter between a connection and a session, and that Diameter messages for
messages for multiple sessions are all multiplexed through a single multiple sessions are all multiplexed through a single connection.
connection.
2.7 Peer Table 2.6 Peer Table
The Diameter Peer Table is used in message forwarding, and referenced The Diameter Peer Table is used in message forwarding, and referenced
by the Realm Routing Table. A Peer Table entry contains the following by the Realm Routing Table. A Peer Table entry contains the following
fields: fields:
- Host identity. following the conventions described for the - Host identity. following the conventions described for the
DiameterIdentity derived AVP data format in section 4.4. This DiameterIdentity derived AVP data format in section 4.4. This
field contains the contents of the Origin-Host AVP found in the field contains the contents of the Origin-Host AVP found in the
CER or CEA message. CER or CEA message.
- Status. This is the state of the peer entry, and MUST match one - Status. This is the state of the peer entry, and MUST match one
of the values listed in section 5.6. of the values listed in section 5.6.
- Role. This field specifies whether a peer is a primary,
secondary or alternate.
- Static or Dynamic. Specifies whether a peer entry was statically - Static or Dynamic. Specifies whether a peer entry was statically
configured, or dynamically discovered. configured, or dynamically discovered.
- Expiration time. Specifies the time which dynamically discovered - Expiration time. Specifies the time at which dynamically
peer table entries are to be either refreshed, or expired. discovered peer table entries are to be either refreshed, or
expired.
- TLS Enabled. Specifies whether TLS is to be used when - TLS Enabled. Specifies whether TLS is to be used when
communicating with the peer. communicating with the peer.
- Additional security information, when needed (e.g. keys, - Additional security information, when needed (e.g. keys,
certificates) certificates)
2.8 Realm-Based Routing Table 2.7 Realm-Based Routing Table
All Realm-Based routing lookups are performed against what is All Realm-Based routing lookups are performed against what is
commonly known as the Realm Routing Table (see section 12.0). A Realm commonly known as the Realm Routing Table (see section 12.0). A Realm
Routing Table Entry contains the following fields: Routing Table Entry contains the following fields:
- Realm Name. This is the field that is typically used as a - Realm Name. This is the field that is typically used as a
primary key in the routing table lookups. Note that some primary key in the routing table lookups. Note that some
implementations perform their lookups based on longest-match- implementations perform their lookups based on longest-match-
from-the-right on the realm rather than requiring an exact from-the-right on the realm rather than requiring an exact
match. match.
- Application Identifier. It is possible for a route entry to have - Application Identifier. A route entry can have a different
a different destination based on the Acct-Application-Id (for destination based on the Acct-Application-Id for accounting
accounting messages) or Auth-Application-Id (for non-accounting messages) or Auth-Application-Id (for non-accounting messages)
messages) of the message. This field is typically used as a of the message. This field MUST be used as a secondary key field
secondary key field in routing table lookups. in routing table lookups.
- Local Action. The Local Action field is used to identify how a - Local Action. The Local Action field is used to identify how a
message should be treated. The following actions are supported: message should be treated. The following actions are supported:
1. LOCAL - Diameter messages that resolve to a route entry 1. LOCAL - Diameter messages that resolve to a route entry
with the Local Action set to Local can be satisfied with the Local Action set to Local can be satisfied
locally, and do not need to be routed to another server. locally, and do not need to be routed to another server.
2. RELAY - All Diameter messages that fall within this 2. RELAY - All Diameter messages that fall within this
category MUST be routed to a next hop server, without category MUST be routed to a next hop server, without
modifying any non-routing AVPs. See section 6.1.8 for modifying any non-routing AVPs. See section 6.1.8 for
relaying guidelines relaying guidelines
3. PROXY - All Diameter messages that fall within this 3. PROXY - All Diameter messages that fall within this
category MUST be routed to a next hop server. The local category MUST be routed to a next hop server. The local
server MAY apply its local policies to the message by server MAY apply its local policies to the message by
including new AVPs to the message prior to routing. See including new AVPs to the message prior to routing. See
section 6.1.8 for proxying guidelines. section 6.1.8 for proxying guidelines.
4. REDIRECT - Diameter messages that fall within this 4. REDIRECT - Diameter messages that fall within this
category MUST have the identity of the home Diameter category MUST have the identity of the home Diameter
server(s) appended, and returned to the sender of the server(s) appended, and returned to the sender of the
message. See section 6.1.7 for redirect guidelines. message. See section 6.1.7 for redirect guidelines.
- Server Identifier. One or more servers the message is to be - Server Identifier. One or more servers the message is to be
routed to. These servers MUST also be present in the Peer routed to. These servers MUST also be present in the Peer table.
table. When the Local Action is set to RELAY or PROXY, this When the Local Action is set to RELAY or PROXY, this field
field contains the identity of the server(s) the message must be contains the identity of the server(s) the message must be
routed to. When the Local Action field is set to REDIRECT, this routed to. When the Local Action field is set to REDIRECT, this
field contains the identity of one or more servers the message field contains the identity of one or more servers the message
should be redirected to. should be redirected to.
- Static or Dynamic. Specifies whether a route entry was - Static or Dynamic. Specifies whether a route entry was
statically configured, or dynamically discovered. statically configured, or dynamically discovered.
- Expiration time. Specifies the time which a dynamically - Expiration time. Specifies the time which a dynamically
discovered route table entry expires. discovered route table entry expires.
It is important to note that Diameter agents MUST support at least It is important to note that Diameter agents MUST support at least
one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents one of the LOCAL, RELAY, PROXY or REDIRECT modes of operation. Agents
do not need to support all modes of operation in order to conform do not need to support all modes of operation in order to conform
with the protocol specification, but MUST follow the protocol with the protocol specification, but MUST follow the protocol
compliance guidelines in section 2.0. Relay agents MUST NOT reorder compliance guidelines in section 2.0. Relay agents MUST NOT reorder
AVPs, and proxies MUST NOT reorder AVPs. AVPs, and proxies MUST NOT reorder AVPs.
The routing table MAY include a default entry which MUST be used for The routing table MAY include a default entry that MUST be used for
any requests not matching any of the other entries. The routing table any requests not matching any of the other entries. The routing table
MAY consist of only such an entry. MAY consist of only such an entry.
When a request is routed, the target server MUST have advertised the When a request is routed, the target server MUST have advertised the
Application Identifier (see section 2.5) for the given message, or Application Identifier (see section 2.5) for the given message, or
have advertised itself as a relay or proxy agent. Oherwise an error have advertised itself as a relay or proxy agent. Otherwise, an error
is returned with the Result-Code AVP set to is returned with the Result-Code AVP set to
DIAMETER_UNABLE_TO_DELIVER. DIAMETER_UNABLE_TO_DELIVER.
2.9 Role of Diameter Agents 2.8 Role of Diameter Agents
In addition to client and servers, the Diameter protocol introduces In addition to client and servers, the Diameter protocol introduces
relay, proxy and redirect agents, each of which is defined in Section relay, proxy, redirect, and translation agents, each of which is
1.3. These Diameter agents are useful for several reasons: defined in Section 1.3. These Diameter agents are useful for several
reasons:
- They can distribute administration of systems to a configurable - They can distribute administration of systems to a configurable
grouping, including the maintenance of security associations. grouping, including the maintenance of security associations.
- They can be used for concentration of requests from an number of - They can be used for concentration of requests from an number of
co-located or distributed NAS equipment sets to a set of like co-located or distributed NAS equipment sets to a set of like
user groups. user groups.
- They can do value-added processing to the requests or responses. - They can do value-added processing to the requests or responses.
- They can be used for load balancing. - They can be used for load balancing.
- A complex network will have multiple authentication sources, - A complex network will have multiple authentication sources,
they can sort requests and forward towards the correct target. they can sort requests and forward towards the correct target.
The Diameter protocol requires that agents maintain transaction The Diameter protocol requires that agents maintain transaction
state, which is used for failover purposes. Transaction state implies state, which is used for failover purposes. Transaction state implies
that upon forwarding a request, it's Hop-by-Hop identifier is saved, that upon forwarding a request, its Hop-by-Hop identifier is saved;
the field is replaced with a locally unique identifier, which is the field is replaced with a locally unique identifier, which is
restored to its original value when the corresponding answer is restored to its original value when the corresponding answer is
received. The request's state is released upon receipt of the answer. received. The request's state is released upon receipt of the answer.
A stateless agent is one that only maintains transaction state. A stateless agent is one that only maintains transaction state.
The Proxy-Info AVP allows stateless agents to add local state to a The Proxy-Info AVP allows stateless agents to add local state to a
Diameter request, with the guarantee that the same state will be Diameter request, with the guarantee that the same state will be
present in the answer. However, the protocol's failover procedures present in the answer. However, the protocol's failover procedures
require that agents maintain a copy of pending requests. require that agents maintain a copy of pending requests.
A stateful agent is one that maintains session state information, by A stateful agent is one that maintains session state information; by
keeping track of all authorized active sessions. Each authorized keeping track of all authorized active sessions. Each authorized
session is bound to a particular service, and its state is considered session is bound to a particular service, and its state is considered
active either until it is notified otherwise, or by expiration. Each active either until it is notified otherwise, or by expiration. Each
authorized session has a expiration, which is communicated by authorized session has an expiration, which is communicated by
Diameter servers via the Session-Timeout AVP. Diameter servers via the Session-Timeout AVP.
Maintaining session state MAY be useful in certain applications, such Maintaining session state MAY be useful in certain applications, such
as: as:
- Protocol translation (e.g. RADIUS <-> Diameter) - Protocol translation (e.g. RADIUS <-> Diameter)
- Limiting resources authorized to a particular user - Limiting resources authorized to a particular user
- Per user or transaction auditing - Per user or transaction auditing
A Diameter agent MAY act in a stateful manner for some requests, A Diameter agent MAY act in a stateful manner for some requests and
while be stateless for others. A Diameter implementation MAY act as be stateless for others. A Diameter implementation MAY act as one
one type of agent for some requests, and as another type of agent for type of agent for some requests, and as another type of agent for
others. others.
2.9.1 Relay Agents 2.8.1 Relay Agents
Relay Agents are Diameter agents that accept requests and route Relay Agents are Diameter agents that accept requests and route
messages to other Diameter agents based on information found in the messages to other Diameter nodes based on information found in the
messages (e.g. Destination-Realm). This routing decision is performed messages (e.g. Destination-Realm). This routing decision is performed
using a list of supported realms, and known peers. This is known as using a list of supported realms, and known peers. This is known as
the Diameter Routing Table, as is defined further in section 2.8. the Realm Routing Table, as is defined further in section 2.8.
Relays MAY be used to aggregate requests from multiple Network Access Relays MAY be used to aggregate requests from multiple Network Access
Servers (NASes) within a common geographical area (POP). The use of Servers (NASes) within a common geographical area (POP). The use of
Relays is advantageous since it eliminates the need for NASes to be Relays is advantageous since it eliminates the need for NASes to be
configured with the necessary security information they would configured with the necessary security information they would
otherwise require to communicate with Diameter servers in other otherwise require to communicate with Diameter servers in other
realms. Likewise, this reduces the configuration load on Diameter realms. Likewise, this reduces the configuration load on Diameter
servers that would otherwise be necessary when NASes are added, servers that would otherwise be necessary when NASes are added,
changed or deleted. changed or deleted.
Relays modify Diameter messages by inserting, and removing, routing Relays modify Diameter messages by inserting, and removing routing
information, but do not modify any other portion of a message. information, but do not modify any other portion of a message.
Further, Relays inherent simplicity implies that they are stateless, Further, Relays' inherent simplicity implies that they are stateless
and therefore SHOULD NOT maintain session state, but MUST maintain and therefore SHOULD NOT maintain session state but MUST maintain
transaction state. transaction state.
+------+ ---------> +------+ ---------> +------+ +------+ ---------> +------+ ---------> +------+
| | 1. Request | | 2. Request | | | | 1. Request | | 2. Request | |
| NAS | | DRL | | HMS | | NAS | | DRL | | HMS |
| | 4. Answer | | 3. Answer | | | | 4. Answer | | 3. Answer | |
+------+ <--------- +------+ <--------- +------+ +------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com mno.net mno.net abc.com
Figure 2: Relaying of Diameter messages Figure 2: Relaying of Diameter messages
skipping to change at page 22, line 16 skipping to change at page 24, line 29
and relays the message to HMS, which is abc.com's Home Diameter and relays the message to HMS, which is abc.com's Home Diameter
Server. HMS identifies that the request can be locally supported (via Server. HMS identifies that the request can be locally supported (via
the realm), processes the authentication and/or authorization the realm), processes the authentication and/or authorization
request, and replies with an answer, which is routed back to NAS request, and replies with an answer, which is routed back to NAS
using saved transaction state. using saved transaction state.
Since Relays do not perform any application level processing, they Since Relays do not perform any application level processing, they
provide relaying services for all Diameter applications, and provide relaying services for all Diameter applications, and
therefore MUST advertise the Relay Application Identifier. therefore MUST advertise the Relay Application Identifier.
2.9.2 Proxy Agents 2.8.2 Proxy Agents
Similarly to Relays, Proxy agents route Diameter messages using the Similarly to Relays, Proxy agents route Diameter messages using the
Diameter Routing Table. However, they differ since they modify Diameter Routing Table. However, they differ since they modify
messages to implement policy enforcement. This requires that proxies messages to implement policy enforcement. This requires that proxies
maintain the state of their downstream peers (e.g. access devices) to maintain the state of their downstream peers (e.g. access devices) to
enforce resource usage, provide admission control, and provisioning. enforce resource usage, provide admission control, and provisioning.
It is important to note that although proxies MAY provide a value-add 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 function for NASes, they do not allow access devices to use the
Diameter CMS Security application, since modifying messages breaks Diameter CMS Security application, since modifying messages breaks
skipping to change at page 22, line 39 skipping to change at page 25, line 5
Proxies MAY be used in call control centers or access ISPs that Proxies MAY be used in call control centers or access ISPs that
provide outsourced connections, they can monitor the number and types provide outsourced connections, they can monitor the number and types
of ports in use, and make allocation and admission decisions of ports in use, and make allocation and admission decisions
according to their configuration. according to their configuration.
Proxies that wish to limit resources MUST be stateful, and all Proxies that wish to limit resources MUST be stateful, and all
Proxies MUST maintain transaction state. Proxies MUST maintain transaction state.
Proxy agents MUST NOT allow CMS security to be established between Proxy agents MUST NOT allow CMS security to be established between
two peers if it expects to modify ANY non-routing AVP in messages two peers if it expects to modify ANY non-routing AVP in messages
exchanged between the peers. See [11] for more information. exchanged between the peers. See [CMS] for more information.
Since enforcing policies requires an understanding of the service Since enforcing policies requires an understanding of the service
being provided, Proxies MUST only advertise the Diameter applications being provided, Proxies MUST only advertise the Diameter applications
they support. they support.
2.9.3 Redirect Agents 2.8.3 Redirect Agents
Redirect agents provide Realm to Server address resolution, and use Redirect agents provide Realm to Server address resolution and MAY
the Diameter routing table to determine where a given request should also provide User to Server address resolution. These redirect agents
be forwarded. When a request is received by a redirect agent, a would make use of the Diameter routing table or optionally, a user
special answer is created, which includes the identity of the table to determine where a given request should be forwarded. When a
Diameter server(s) the originator of the request should contact request is received by a redirect agent, a special answer is created,
directly. which includes the identity of the Diameter server(s) the originator
of the request should contact directly.
Redirect agents are useful in scenarios where the Diameter routing Redirect agents are useful in scenarios where the Diameter routing
configuration needs to be centralized. An example is a redirect agent configuration needs to be centralized. An example is a redirect agent
that provides services to all members of a consortium, but does not that provides services to all members of a consortium, but does not
wish to be burdened with relaying all messages between realms. This wish to be burdened with relaying all messages between realms. This
scenario is advantageous since it does not require that the scenario is advantageous since it does not require that the
consortium provide routing updates to its members when changes are consortium provide routing updates to its members when changes are
made to a member's infrastructure. made to a member's infrastructure.
Since redirect agents do not relay messages, and only return an Since redirect agents do not relay messages, and only return an
answer with the information necessary for Diameter agents to answer with the information necessary for Diameter agents to
communicate directly, they do not modify messages. Since redirect communicate directly, they do not modify messages. Since redirect
agents do not receive answer messages, they cannot maintain session agents do not receive answer messages, they cannot maintain session
state. Further, since redirect agents never relay requests, they are state. Further, since redirect agents never relay requests, they are
not required to maintain transaction state. not required to maintain transaction state.
The example provided in Figure 3 depicts a request issued from the The example provided in Figure 3 depicts a request issued from the
access device, NAS, for the user bob@abc.com. The message is access device, NAS, for the user bob@abc.com. The message is
forwarded by the NAS to its relay, DRL, which does not have a routing forwarded by the NAS to its relay, DRL, which does not have a routing
entry in its Diameter Routing Table for abc.com. DRL has a default entry in its Diameter Routing Table for abc.com. DRL has a default
route configured to DRD, which is a redirect agent that returns a route configured to DRD, which is a redirect agent that returns a
redirect notification to DRL, as well as HMS' contact information. redirect notification to DRL, as well as HMS' contact information.
Upon receipt of the redirect notification, DRL establishes a Upon receipt of the redirect notification, DRL establishes a
transport connection with HMS, if one doesn't already exist, and transport connection with HMS, if one doesn't already exist, and
skipping to change at page 24, line 7 skipping to change at page 26, line 27
| | 6. Answer | | 5. Answer | | | | 6. Answer | | 5. Answer | |
+------+ <--------- +------+ <--------- +------+ +------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com mno.net mno.net abc.com
Figure 3: Redirecting a Diameter Message Figure 3: Redirecting a Diameter Message
Since Redirect agents do not perform any application level Since Redirect agents do not perform any application level
processing, they provide relaying services for all Diameter processing, they provide relaying services for all Diameter
applications, and therefore MUST advertise the Relay Application applications, and therefore MUST advertise the Relay Application
Identifier. Identifier.
2.9.4 Translation Agents 2.8.4 Translation Agents
A Translation Agent is a device that provides translation between two A Translation Agent is a device that provides translation between two
protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation protocols (e.g. RADIUS<->Diameter, TACACS+<->Diameter). Translation
agents are likely to be used as aggregation servers to communicate agents are likely to be used as aggregation servers to communicate
with a Diameter infrastructure, while allowing for the embedded with a Diameter infrastructure, while allowing for the embedded
systems to be migrated at a slower pace. systems to be migrated at a slower pace.
Given that the Diameter protocol introduces the concept of long-lived Given that the Diameter protocol introduces the concept of long-lived
authorized sessions, translation agents MUST be stateful and MUST authorized sessions, translation agents MUST be session stateful and
maintain transaction state. MUST maintain transaction state.
Translation of messages can only occur if the agent recognizes the Translation of messages can only occur if the agent recognizes the
application of a particular request, and therefore MUST only application of a particular request, and therefore translation agents
advertise their locally supported applications. MUST only advertise their locally supported applications.
+------+ ---------> +------+ ---------> +------+ +------+ ---------> +------+ ---------> +------+
| | RADIUS Request | | Diameter Request | | | | RADIUS Request | | Diameter Request | |
| NAS | | TLA | | HMS | | NAS | | TLA | | HMS |
| | RADIUS Answer | | Diameter Answer | | | | RADIUS Answer | | Diameter Answer | |
+------+ <--------- +------+ <--------- +------+ +------+ <--------- +------+ <--------- +------+
mno.net mno.net abc.com mno.net mno.net abc.com
Figure 4: Translation of RADIUS to Diameter Figure 4: Translation of RADIUS to Diameter
3.0 Diameter Header 3.0 Diameter Header
skipping to change at page 25, line 35 skipping to change at page 27, line 40
Message Length Message Length
The Message Length field is three octets and indicates the length The Message Length field is three octets and indicates the length
of the Diameter message including the header fields. of the Diameter message including the header fields.
Command Flags Command Flags
The Command Flags field is eight bits. The following bits are The Command Flags field is eight bits. The following bits are
assigned: assigned:
R(equest) - If set, the message is a request. If cleared, the R(equest) - If set, the message is a request. If cleared, the
message is an answer. message is an answer.
P(roxiable) - If set, the message MAY be proxied. If cleared, P(roxiable) - If set, the message MAY be proxied, relayed or
the message MUST be locally processed. redirected. If cleared, the message MUST be
locally processed.
E(rror) - If set, the message contains a protocol error, E(rror) - If set, the message contains a protocol error,
and the message will not conform to the ABNF and the message will not conform to the ABNF
described for this command. Messages with the described for this command. Messages with the 'E'
'E' bit set is commonly referred to as an error bit set are commonly referred to as an error
message. This bit MUST NOT be set in request messages. This bit MUST NOT be set in request
messages. See section 7.2. messages. See section 7.2.
r(eserved) - these flag bits are reserved for future use, and r(eserved) - these flag bits are reserved for future use, and
MUST be set to zero, otherwise an error MUST be MUST be set to zero, otherwise an error MUST be
sent to the sender. sent to the sender.
Command-Code Command-Code
The Command-Code field is three octets, and is used in order to The Command-Code field is three octets, and is used in order to
communicate the command associated with the message. The 24-bit communicate the command associated with the message. The 24-bit
address space is managed by IANA (see section 11.2). address space is managed by IANA (see section 11.2).
Vendor-ID Vendor-ID
In the event that the Command-Code field contains a vendor In the event that the Command-Code field contains a vendor
specific command, the four octet Vendor-ID field contains the IANA specific command, the four-octet Vendor-ID field contains the IANA
assigned "SMI Network Management Private Enterprise Codes" [2] assigned "SMI Network Management Private Enterprise Codes" [ASSIGN
value. If the Command-Code field contains an IETF standard NO] value. If the Command-Code field contains an IETF standard
Command, the Vendor-ID field MUST be set to zero (0). Any vendor Command, the Vendor-ID field MUST be set to zero (0). Any vendor
wishing to implement a vendor-specific Diameter command MUST use wishing to implement a vendor-specific Diameter command MUST use
their own Vendor-ID along with their privately managed Command- their own Vendor-ID along with their privately managed Command-
Code address space, guaranteeing that they will not collide with Code address space, guaranteeing that they will not collide with
any other vendor's vendor-specific command, nor with future IETF any other vendor's vendor-specific command, nor with future IETF
applications. applications. All vendor-specific Diameter commands require
Information RFCs documenting the command.
Hop-by-Hop Identifier Hop-by-Hop Identifier
The Hop-by-Hop Identifier is an Unsigned32 field and aids in The Hop-by-Hop Identifier is an Unsigned32 field and aids in
matching requests and replies. The sender MUST ensure that the matching requests and replies. The sender MUST ensure that the
Hop-by-Hop identifier in a request is unique on a given connection Hop-by-Hop identifier in a request is unique on a given connection
at any given time, and MAY attempt to ensure that the number is at any given time, and MAY attempt to ensure that the number is
unique across reboots. The sender of an Answer message MUST ensure unique across reboots. The sender of an Answer message MUST ensure
that the Hop-by-Hop Identifier field contains the same value that that the Hop-by-Hop Identifier field contains the same value that
was found in the corresponding request. The Hop-by-Hop identifier was found in the corresponding request. The Hop-by-Hop identifier
is normally a monotonically increasing number, whose start value is normally a monotonically increasing number, whose start value
was randomly generated. An answer message that is received with an was randomly generated. An answer message that is received with an
unknown Hop-by-Hop Identifier MUST be discarded. unknown Hop-by-Hop Identifier MUST be discarded.
End-to-End Identifier End-to-End Identifier
The End-to-End Identifier is an Unsigned32 field and is used to The End-to-End Identifier is an Unsigned32 field and is used to
detect duplicate messages. Upon reboot implementations MAY set the detect duplicate messages. Upon reboot implementations MAY set the
high order 12 bits to contain the low order 12 bits of current high order 12 bits to contain the low order 12 bits of current
time, and the low order 20 bits to a random value. Senders of time, and the low order 20 bits to a random value. Senders of
request messages MUST insert a unique identifier on each message. request messages MUST insert a unique identifier on each message.
The identifier MUST remain locally unique for a period of at least The identifier MUST remain locally unique for a period of at least
4 minutes, even across reboots. The originator of an Answer 4 minutes, even across reboots. The originator of an Answer
message MUST ensure that the End-to-End Identifier field contains message MUST ensure that the End-to-End Identifier field contains
the same value that was found in the corresponding request. The the same value that was found in the corresponding request. The
End-to-End Identifier MUST NOT be modified by relay agents. The End-to-End Identifier MUST NOT be modified by relay agents. The
combination of the Origin-Host and this field is used to detect combination of the Origin-Host and this field is used to detect
duplicates. Duplicate requests SHOULD cause the same answer to be duplicates. Duplicate requests SHOULD cause the same answer to be
transmitted (modulo the hop-by-hop Identifier field and any transmitted (modulo the hop-by-hop Identifier field and any
routing AVPs that may be present), and MUST NOT affect any state routing AVPs that may be present), and MUST NOT affect any state
that was set when the original request was processed. Duplicate that was set when the original request was processed. Duplicate
answer messages that are to be locally consumed (see Section 6.2) answer messages that are to be locally consumed (see Section 6.2)
SHOULD be silently discarded. SHOULD be silently discarded.
AVPs AVPs
AVPs are a method of encapsulating information relevant to the AVPs are a method of encapsulating information relevant to the
Diameter message. See section 4. for more information on AVPs. Diameter message. See section 4 for more information on AVPs.
3.1 Command Codes 3.1 Command Codes
Each command Request/Answer pair is assigned a command code, and the Each command Request/Answer pair is assigned a command code, and the
sub-type (e.g. request or answer) is identified via the 'R' bit in sub-type (i.e. - request or answer) is identified via the 'R' bit in
the Command Flags field of the Diameter header. the Command Flags field of the Diameter header.
Every Diameter message MUST contain a command code in its header's 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 Command-Code field, which is used to determine the action that is to
be taken for a particular message. The following Command Codes are be taken for a particular message. The following Command Codes are
defined in the Diameter base protocol: defined in the Diameter base protocol:
Command-Name Abbrev. Code Reference Command-Name Abbrev. Code Reference
-------------------------------------------------------- --------------------------------------------------------
Abort-Session-Request ASR 274 8.5.1 Abort-Session-Request ASR 274 8.5.1
skipping to change at page 27, line 38 skipping to change at page 29, line 45
Re-Auth-Answer RAA 258 8.3.2 Re-Auth-Answer RAA 258 8.3.2
Session-Termination- STR 275 8.4.1 Session-Termination- STR 275 8.4.1
Request Request
Session-Termination- STA 275 8.4.2 Session-Termination- STA 275 8.4.2
Answer Answer
3.2 Command Code ABNF specification 3.2 Command Code ABNF specification
Every Command Code defined MUST include a corresponding ABNF Every Command Code defined MUST include a corresponding ABNF
specification, which is used to define the AVPs that MUST or MAY be specification, which is used to define the AVPs that MUST or MAY be
present. The following format is used in the definition: present. The following format is used in the definition:
command-def = command-name "::=" diameter-message command-def = command-name "::=" diameter-message
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
command-name = diameter-name command-name = diameter-name
; The command-name has to be Command name, ; The command-name has to be Command name,
; defined in the base or extended Diameter ; defined in the base or extended Diameter
; specifications. ; specifications.
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
diameter-message = header [ *fixed] [ *required] [ *optional] diameter-message = header [ *fixed] [ *required] [ *optional]
[ *fixed] [ *fixed]
header = "< Diameter-Header:" [vendor-id] command-id header = "< Diameter-Header:" [vendor-id] command-id
[r-bit] [p-bit] [e-bit] ">" [r-bit] [p-bit] [e-bit] ">"
vendor-id = 1*DIGIT ":" vendor-id = 1*DIGIT ":"
; The optional vendor-id is used to define ; The optional vendor-id is used to define
; vendor specific commands ; vendor specific commands
command-id = 1*DIGIT command-id = 1*DIGIT
; The Command Code assigned to the command ; The Command Code assigned to the command
r-bit = ", REQ" r-bit = ", REQ"
; If present, the 'R' bit in the Command ; If present, the 'R' bit in the Command
; Flags is set, indicating that the message ; Flags is set, indicating that the message
; is a request, as opposed to an answer. ; is a request, as opposed to an answer.
p-bit = ", PXY" p-bit = ", PXY"
; If present, the 'P' bit in the Command ; If present, the 'P' bit in the Command
; Flags is set, indication that the message ; Flags is set, indicating that the message
; is proxiable. ; is proxiable.
e-bit = ", ERR" e-bit = ", ERR"
; If present, the 'E' bit in the Command ; If present, the 'E' bit in the Command
; Flags is set, indication that the answer ; Flags is set, indicating that the answer
; message contains a Result-Code AVP in ; message contains a Result-Code AVP in
; the "protocol error" class. ; the "protocol error" class.
fixed = [qual] "<" avp-spec ">" fixed = [qual] "<" avp-spec ">"
; Defines the fixed position of an AVP ; Defines the fixed position of an AVP
required = [qual] "{" avp-spec "}" required = [qual] "{" avp-spec "}"
; The AVP MUST be present and can appear ; The AVP MUST be present and can appear
; anywhere in the message. ; anywhere in the message.
optional = [qual] "[" avp-name "]" optional = [qual] "[" avp-name "]"
; The avp-name in the 'optional' rule cannot ; The avp-name in the 'optional' rule cannot
; evaluate to any AVP Name which is included ; evaluate to any AVP Name which is included
; in a fixed or required rule. The AVP can ; in a fixed or required rule. The AVP can
; appear anywhere in the message. ; appear anywhere in the message.
qual = [min] "*" [max] qual = [min] "*" [max]
; See ABNF conventions, RFC 2234 section 6.6. ; See ABNF conventions, RFC 2234 section 6.6.
; The absence of any qualifiers implies that ; The absence of any qualifiers depends on whether
; one and only one such AVP MUST be present. ; it precedes a fixed, required, or optional
; rule. If a fixed or required rule has no
; qualifier, then exactly one such AVP MUST
; be present. If an optional rule has no
; qualifier, then 0 or 1 such AVP may be
; present.
; ;
; NOTE: "[" and "]" have a different meaning ; NOTE: "[" and "]" have a different meaning
; than in ABNF (see the optional rule, above). ; than in ABNF (see the optional rule, above).
; These braces cannot be used to express ; These braces cannot be used to express
; optional fixed rules (such as an optional ; optional fixed rules (such as an optional
; ICV at the end.) To do this, the convention ; ICV at the end.) To do this, the convention
; is '0*1fixed'. ; is '0*1fixed'.
min = 1*DIGIT min = 1*DIGIT
; The minimum number of times the element may ; The minimum number of times the element may
skipping to change at page 29, line 39 skipping to change at page 32, line 5
Example-Request ::= < Diameter-Header: 9999999, REQ, PXY > Example-Request ::= < Diameter-Header: 9999999, REQ, PXY >
{ User-Name } { User-Name }
* { Origin-Host } * { Origin-Host }
* [ AVP ] * [ AVP ]
3.3 Diameter Command Naming Conventions 3.3 Diameter Command Naming Conventions
Diameter commands typically includes one or more English words Diameter commands typically includes one or more English words
followed by the verb Request or Answer. Each English word is followed by the verb Request or Answer. Each English word is
delimited by a hyphen. An acronym for both the request and answer is delimited by a hyphen. A three-letter acronym for both the request
also normally provided. and answer is also normally provided.
An example is a message set used to terminate a session. The command An example is a message set used to terminate a session. The command
name is Session-Terminate-Request and Session-Terminate-Answer, while name is Session-Terminate-Request and Session-Terminate-Answer, while
the acronyms are STR and STA, respectively. the acronyms are STR and STA, respectively.
Both the request and the answer for a given command share the same Both the request and the answer for a given command share the same
command code. The request is identified by the R(equest) bit in the command code. The request is identified by the R(equest) bit in the
Diameter header set to one (1), to ask that a particular action be Diameter header set to one (1), to ask that a particular action be
performed, such as authorizing a user or terminating a session. Once performed, such as authorizing a user or terminating a session. Once
the receiver has completed the request it issues the corresponding the receiver has completed the request it issues the corresponding
skipping to change at page 30, line 16 skipping to change at page 32, line 29
- The request was successful - The request was successful
- The request failed - The request failed
- An additional request must be sent to provide information the - An additional request must be sent to provide information the
peer requires prior to returning a successful or failed answer. peer requires prior to returning a successful or failed answer.
- The receiver could not process the request, but provides - The receiver could not process the request, but provides
information about a Diameter peer that is able to satisfy the information about a Diameter peer that is able to satisfy the
request, known as redirect. request, known as redirect.
Additional information, encoded within AVPs, MAY also be Additional information, encoded within AVPs, MAY also be
included in answer messages. included in answer messages.
4.0 Diameter AVPs 4.0 Diameter AVPs
Diameter AVPs carry specific authentication, accounting, Diameter AVPs carry specific authentication, accounting,
authorization, routing and security information as well as authorization, routing and security information as well as
configuration details for the request and reply. configuration details for the request and reply.
Some AVPs MAY be listed more than once. The effect of such an AVP is 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. specific, and is specified in each case by the AVP description.
Each AVP of type OctetString MUST be padded to align on a 32 bit Each AVP of type OctetString MUST be padded to align on a 32-bit
boundary, while other AVP types align naturally. NULL bytes are added boundary, while other AVP types align naturally. NULL bytes are added
to the end of the AVP Data field till a word boundary is reached. The to the end of the AVP Data field till a word boundary is reached. The
length of the padding is not reflected in the AVP Length field. length of the padding is not reflected in the AVP Length field.
4.1 AVP Header 4.1 AVP Header
The fields in the AVP header MUST be sent in network byte order. The The fields in the AVP header MUST be sent in network byte order. The
format of the header is: format of the header is:
0 1 2 3 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Code | | AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V M P r r r r r| AVP Length | |V M P r r r r r| AVP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-ID (opt) | | Vendor-ID (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ... | Data ...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
AVP Code AVP Code
The AVP Code, combined with the Vendor-Id field, identifies the The AVP Code, combined with the Vendor-Id field, identifies the
attribute uniquely. The first 256 AVP numbers, with the Vendor-Id attribute uniquely. AVP numbers 0 through 255, with the Vendor-Id
set to zero (0) are reserved for backward compatibility with set to zero (0) are reserved for backward compatibility with
RADIUS and are to be interpreted as per NASREQ [7]. AVP numbers RADIUS. AVP numbers 256 and above are used for Diameter, which are
256 and above are used for Diameter, which are allocated by IANA allocated by IANA (see section 11.1).
(see section 11.1).
AVP Flags AVP Flags
The AVP Flags field informs the receiver how each attribute must The AVP Flags field informs the receiver how each attribute must
be handled. The 'r' (reserved) bits are unused and SHOULD be set be handled. The 'r' (reserved) bits are unused and SHOULD be set
to 0. Note that subsequent Diameter applications MAY define to 0. Note that subsequent Diameter applications MAY define
additional bits within the AVP Header, and an unrecognized bit additional bits within the AVP Header, and an unrecognized bit
SHOULD be considered an error. The 'P' bit is defined in [11]. SHOULD be considered an error. The 'P' bit is defined in [CMS].
The 'M' Bit, known as the Mandatory bit, indicates whether support The 'M' Bit, known as the Mandatory bit, indicates whether support
of the AVP is required. If an AVP with the 'M' bit set is received of the AVP is required. If an AVP with the 'M' bit set is received
by a Diameter client, server or proxy and either the AVP or its by a Diameter client, server, proxy, or translation agent and
value is unrecognized, the message MUST be rejected. Diameter either the AVP or its value is unrecognized, the message MUST be
Relay and Redirect agents MUST NOT reject messages with rejected. Diameter Relay and Redirect agents MUST NOT reject
unrecognized AVPs. messages with unrecognized AVPs.
A Diameter node that sets the 'M' bit in an AVP that is not The 'M' bit MUST be set according to the rules defined for the AVP
defined in a given message's ABNF is at fault if the message is containing it. In order to preserve interoperability, a Diameter
rejected. In order to provide service to the user, the node at implementation MUST be able to exclude from a Diameter message any
fault MUST re-issue a request either without the AVP, or without Mandatory AVP which is neither defined in the base Diameter
setting its 'M' bit. Alternatively, the node at fault MAY decide standard nor in any of the Diameter Application specifications
to simply not provide service to the user. governing the message in which it appears. It MAY do this in one
of the following ways:
A Diameter node that rejects a message due to an unrecognized AVP 1) If a message is rejected because it contains a Mandatory AVP
with the 'M' bit set, and the AVP in question is defined in the which is neither defined in the base Diameter standard nor in
message's ABNF, is at fault. In most cases the initiator of the any of the Diameter Application specifications governing the
failing request will not provide service to the user. message in which it appears, the implementation may resend the
message without the AVP, possibly inserting additional standard
AVPs instead.
2) A configuration option may be provided on a system wide, per
peer, or per realm basis that would allow/prevent particular
Mandatory AVPs to be sent. Thus an administrator could change
the configuration to avoid interoperability problems.
Diameter implementations are required to support all Mandatory
AVPs which are allowed by the message's formal syntax and defined
either in the base Diameter standard or in one of the Diameter
Application specifications governing the message.
AVPs with the 'M' bit cleared are informational only and a AVPs with the 'M' bit cleared are informational only and a
receiver that receives a message with such an AVP that is not receiver that receives a message with such an AVP that is not
supported, or whose value is not supported, MAY simply ignore the supported, or whose value is not supported, MAY simply ignore the
AVP. AVP.
The 'V' bit, known as the Vendor-Specific bit, indicates whether The 'V' bit, known as the Vendor-Specific bit, indicates whether
the optional Vendor-ID field is present in the AVP header. When the optional Vendor-ID field is present in the AVP header. When
set the AVP Code belongs to the specific vendor code address set the AVP Code belongs to the specific vendor code address
space. space.
skipping to change at page 31, line 49 skipping to change at page 34, line 27
supported, or whose value is not supported, MAY simply ignore the supported, or whose value is not supported, MAY simply ignore the
AVP. AVP.
The 'V' bit, known as the Vendor-Specific bit, indicates whether The 'V' bit, known as the Vendor-Specific bit, indicates whether
the optional Vendor-ID field is present in the AVP header. When the optional Vendor-ID field is present in the AVP header. When
set the AVP Code belongs to the specific vendor code address set the AVP Code belongs to the specific vendor code address
space. space.
Unless otherwise noted, AVPs will have the following default AVP Unless otherwise noted, AVPs will have the following default AVP
Flags field settings: Flags field settings:
The 'M' bit MUST be set. The 'V' bit MUST NOT be set. The 'M' bit MUST be set. The 'V' bit MUST NOT be set.
AVP Length AVP Length
The AVP Length field is three octets, and indicates the length of The AVP Length field is three octets, and indicates the number of
this AVP including the AVP Code, AVP Length, AVP Flags, Reserved, octets in this AVP including the AVP Code, AVP Length, AVP Flags,
the Vendor-ID field (if present) and the AVP data. If a message is Vendor-ID field (if present) and the AVP data. If a message is
received with an invalid attribute length, the message SHOULD be received with an invalid attribute length, the message SHOULD be
rejected. rejected.
4.2 Optional Header Elements 4.2 Optional Header Elements
The AVP Header contains one optional field. This field is only The AVP Header contains one optional field. This field is only
present if the respective bit-flag is enabled. present if the respective bit-flag is enabled.
Vendor-ID Vendor-ID
The Vendor-ID field is present if the 'V' bit is set in the AVP The Vendor-ID field is present if the 'V' bit is set in the AVP
Flags field. The optional four octet Vendor-ID field contains the Flags field. The optional four octet Vendor-ID field contains the
IANA assigned "SMI Network Management Private Enterprise Codes" IANA assigned "SMI Network Management Private Enterprise Codes"
[2] value, encoded in network byte order. Any vendor wishing to [ASSIGN NO] value, encoded in network byte order. Any vendor
implement a vendor-specific Diameter AVP MUST use their own wishing to implement a vendor-specific Diameter AVP MUST use their
Vendor-ID along with their privately managed AVP address space, own Vendor-ID along with their privately managed AVP address
guaranteeing that they will not collide with any other vendor's space, guaranteeing that they will not collide with any other
vendor-specific AVP, nor with future IETF applications. vendor's vendor-specific AVP, nor with future IETF applications.
A vendor ID value of zero (0) corresponds to the IETF adopted AVP A vendor ID value of zero (0) corresponds to the IETF adopted AVP
values, as managed by the IANA. Since the absence of the vendor ID values, as managed by the IANA. Since the absence of the vendor ID
field implies that the AVP in question is not vendor specific, field implies that the AVP in question is not vendor specific,
implementations SHOULD not use the zero (0) vendor ID. implementations SHOULD NOT use the zero (0) vendor ID.
4.3 AVP Base Data Format 4.3 AVP Base Data Format
The Data field is zero or more octets and contains information The Data field is zero or more octets and contains information
specific to the Attribute. The format and length of the Data field is specific to the Attribute. The format and length of the Data field is
determined by the AVP Code and AVP Length fields. The format of the determined by the AVP Code and AVP Length fields. The format of the
Data field MUST be one of the following base data types or a data Data field MUST be one of the following base data types or a data
type derived from the base data types. In the event that a new AVP type derived from the base data types. In the event that a new AVP
Base Data Format is needed, a new version of this RFC must be Base Data Format is needed, a new version of this RFC must be
created. created.
OctetString OctetString
The data contains arbitrary data of variable length. Unless The data contains arbitrary data of variable length. Unless
otherwise noted, the AVP Length field MUST be set to at least 8 otherwise noted, the AVP Length field MUST be set to at least
(12 if the 'V' bit is enabled). AVP Values of this type that 8(12 if the 'V' bit is enabled). AVP Values of this type that
do not align on a 32-bit boundary MUST have the necessary are not a multiple of 4 octets in length be followed by the
padding. necessary padding so that the next AVP (if any) will start on a
32-bit boundary.
Integer32 Integer32
32 bit signed value, in network byte order. The AVP Length 32 bit signed value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit is enabled). field MUST be set to 12 (16 if the 'V' bit is enabled).
Integer64 Integer64
64 bit signed value, in network byte order. The AVP Length 64 bit signed value, in network byte order. The AVP Length
field MUST be set to 16 (20 if the 'V' bit is enabled). field MUST be set to 16 (20 if the 'V' bit is enabled).
Unsigned32 Unsigned32
32 bit unsigned value, in network byte order. The AVP Length 32 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 12 (16 if the 'V' bit is enabled). field MUST be set to 12 (16 if the 'V' bit is enabled).
Unsigned64 Unsigned64
64 bit unsigned value, in network byte order. The AVP Length 64 bit unsigned value, in network byte order. The AVP Length
field MUST be set to 16 (20 if the 'V' bit is enabled). field MUST be set to 16 (20 if the 'V' bit is enabled).
Float32 Float32
This represents floating point values of single precision as This represents floating point values of single precision as
described by [30]. The 32 bit value is transmitted in network described by [FLOATPOINT]. The 32-bit value is transmitted in
byte order. The AVP Length field MUST be set to 12 (16 if the network byte order. The AVP Length field MUST be set to 12 (16
'V' bit is enabled). if the 'V' bit is enabled).
Float64 Float64
This represents floating point values of double precision as This represents floating point values of double precision as
described by [30]. The 64 bit value is transmitted in network described by [FLOATPOINT]. The 64-bit value is transmitted in
byte order. The AVP Length field MUST be set to 16 (20 if the network byte order. The AVP Length field MUST be set to 16 (20
'V' bit is enabled). if the 'V' bit is enabled).
Grouped Grouped
The Data field is specified as a sequence of AVPs. Each of The Data field is specified as a sequence of AVPs. Each of
these AVPs follows - in the order in which they are specified - these AVPs follows - in the order in which they are specified -
including their headers and padding. The AVP Length field is including their headers and padding. The AVP Length field is
set to 8 (12 if the 'V' bit is enabled) plus the total length set to 8 (12 if the 'V' bit is enabled) plus the total length
of all included AVPs, including their headers and padding. of all included AVPs, including their headers and padding. Thus
the AVP length field of an AVP of type Grouped is always a
multiple of 4.
4.4 Derived AVP Data Formats Derived AVP Data Formats
In addition to using the AVP Base Data Formats, applications may In addition to using the AVP Base Data Formats, applications may
define data formats derived from the AVP Base Data Formats. An define data formats derived from the AVP Base Data Formats. An
application that defines new AVP Derived Data Formats MUST include application that defines new AVP Derived Data Formats MUST include
them in a section entitled "AVP Derived Data Formats", using the same them in a section entitled "AVP Derived Data Formats", using the same
format as the definitions below. Each new definition must be either format as the definitions below. Each new definition must be either
defined or listed with a reference to the RFC that defines the defined or listed with a reference to the RFC that defines the
format. format.
The below AVP Derived Data Formats are commonly used by applications. The below AVP Derived Data Formats are commonly used by applications.
IPAddress IPAddress
The IPAddress format is derived from the OctetString AVP Base The IPAddress format is derived from the OctetString AVP Base
Format. It represents 32 bit (IPv4) [17] or 128 bit (IPv6) [16] Format. It represents 32 bit (IPv4) [IPV4] or 128-bit (IPv6)
address, most significant octet first. The format of the [IPV6] address, most significant octet first. The format of the
address (IPv4 or IPv6) is determined by the length. If the address (IPv4 or IPv6) is determined by the length. If the
attribute value is an IPv4 address, the AVP Length field MUST attribute value is an IPv4 address, the AVP Length field MUST
be 12 (16 if 'V' bit is enabled), otherwise the AVP Length be 12 (16 if 'V' bit is enabled); otherwise, the AVP Length
field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6 field MUST be set to 24 (28 if the 'V' bit is enabled) for IPv6
addresses. addresses.
Time Time
The Time format is derived from the Unsigned32 AVP Base Format. The Time format is derived from the OctetString AVP Base
This is 32 bit unsigned value containing the four most Format. The string MUST contain four octets, in the same format
significant octets returned from NTP [18], in network byte as the first four bytes are in the NTP timestamp format. The
order. NTP Timestamp format is defined in chapter 3 of [SNTP].
This represent the number of seconds since 0h on 1 January 1900 This represents the number of seconds since 0h on 1 January
with respect to the Coordinated Universal Time (UTC). 1900 with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will On 6h 28m 16s UTC, 7 February 2036 the time value will
overflow. NTP [18] describes a procedure to extend the time to overflow. SNTP [SNTP] describes a procedure to extend the time
2104. to 2104. This procedure MUST be used by all DIAMETER nodes.
UTF8String UTF8String
The UTF8String format is derived from the OctetString AVP Base The UTF8String format is derived from the OctetString AVP Base
Format. This is a human readable string represented using the Format. This is a human readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString ISO/IEC IS 10646-1 character set, encoded as an OctetString
using the UTF-8 [24] transformation format described in RFC using the UTF-8 [UFT8] transformation format described in RFC
2279. 2279.
Since additional code points are added by amendments to the Since additional code points are added by amendments to the
10646 standard from time to time, implementations MUST be 10646 standard from time to time, implementations MUST be
prepared to encounter any code point from 0x00000001 to prepared to encounter any code point from 0x00000001 to
0x7fffffff. Byte sequences that do not correspond to the valid 0x7fffffff. Byte sequences that do not correspond to the valid
UTF-8 encoding of a code point or are outside this range are UTF-8 encoding of a code point or are outside this range are
prohibited. Note that since a code point of 0x00000000 is prohibited.
prohibited, no octet will contain a value of 0x00.
The use of control codes SHOULD be avoided. When it is The use of control codes SHOULD be avoided. When it is
necessary to represent a newline, the control code sequence CR necessary to represent a newline, the control code sequence CR
LF SHOULD be used. LF SHOULD be used.
The use of leading or trailing white space SHOULD be avoided. The use of leading or trailing white space SHOULD be avoided.
For code points not directly supported by user interface For code points not directly supported by user interface
hardware or software, an alternative means of entry and hardware or software, an alternative means of entry and
display, such as hexadecimal, MAY be provided. display, such as hexadecimal, MAY be provided.
For information encoded in 7-bit US-ASCII, the UTF-8 encoding For information encoded in 7-bit US-ASCII, the UTF-8 encoding
is identical to the US-ASCII encoding. is identical to the US-ASCII encoding.
UTF-8 may require multiple bytes to represent a single UTF-8 may require multiple bytes to represent a single
character / code point; thus the length of a UTF8String in character / code point; thus the length of an UTF8String in
octets may be different from the number of characters encoded. octets may be different from the number of characters encoded.
Note that the size of an UTF8String is measured in octets, not Note that the size of an UTF8String is measured in octets, not
characters. characters.
DiameterIdentity DiameterIdentity
The DiameterIdentity format is derived from the OctetString AVP The DiameterIdentity format is derived from the OctetString AVP
Base Format. It uses the UTF-8 encoding and has the same Base Format. It uses the UTF-8 encoding and has the same
requirements as the UTF8String. In addition, it must follow requirements as the UTF8String:
the Uniform Resource Identifiers (URI) syntax [29] rules
specified below:
Diameter-Identity = "aaa://" fqdn [ port ] [ transport ] DiameterIdentity = fqdn
[ protocol ] [ transport-security ]
fqdn = Fully Qualified Host Name A Diameter node must be uniquely identified by its
DiameterIdentity, which contains the fqdn of the Diameter node.
If multiple Diameter nodes run on the same host, each Diameter
node MUST be assigned a unique DiameterIdentity. If a Diameter
node can be identified by several FQDNs, one single FQDN should
be picked at startup, and used as the only DiameterIdentity for
that node, whatever the connection it is sent on. The
DiameterIdentity value is used to uniquely identify a Diameter
node for purposes of duplicate connection and routing loop
detection.
port = ":" 1*DIGIT DiameterURI
; One of the ports used to listen for
; incoming connections. ; If absent,
; the default Diameter port (TBD) is
; assumed.
transport-protocol = ( "tcp" | "sctp" | "udp" ) The DiameterURI MUST follow the Uniform Resource Identifiers (URI)
syntax [URI] rules specified below:
transport = ";transport=" transport-protocol "aaa://" fqdn [ port ] [ transport ] [ protocol ]
; One of the transports used to listen
; for incoming connections. If absent,
; the default SCTP [26] protocol is
; assumed. UDP MUST NOT be used when
; the aaa-protocol field is set to
; diameter.
aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) ; No transport security
protocol = ";protocol=" aaa-protocol "aaas://" fqdn [ port ] [ transport ] [ protocol ]
; If absent, the default AAA protocol
; is diameter.
transport-security = ( "none" | "TLS" ) ; Transport security used
; Specifies whether TLS [or other future
; transport layer mechanisms supported] is
; to be used when communicating with the
; peer. The default value is none.
The following are examples of valid Diameter host fqdn = Fully Qualified Host Name
identities:
aaa://host.abc.com;transport=tcp port = ":" 1*DIGIT
aaa://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 a single host cannot ; One of the ports used to listen for ;
listen for incoming connections on the same port on a given incoming connections. ; If absent, ; the
protocol, the DiameterIdentity of any process is guaranteed to default Diameter port (TBD) is ; assumed.
be unique.
Unless a Diameter node is sitting on the border of two routing transport = ";transport=" transport-protocol
domains (e.g. private and public), a Diameter node MUST
advertise the same identity on all connections, via the CER and
CEA's Origin-Host AVP. The same identity advertised in a
connection's CER and CEA MUST be used in any AVP of type
DiameterIdentity sent on that connection.
When comparing AVPs of this format, it is necessary to add any ; One of the transports used to listen ; for
absent fields with the default values prior to the comparison. incoming connections. If absent, ; the default
For example, diameter-host.abc.com would be expanded to SCTP [SCTP] protocol is ; assumed. UDP MUST NOT
aaa://diameter- be used when ; the aaa-protocol field is set to
host.abc.com:TBD;protocol=diameter;transport=sctp; transport- ; diameter.
security=none.
transport-protocol = ( "tcp" | "sctp" | "udp" )
protocol = ";protocol=" aaa-protocol
; If absent, the default AAA protocol ; is
diameter.
aaa-protocol = ( "diameter" | "radius" | "tacacs+" )
The following are examples of valid Diameter host identities:
aaa://host.abc.com;transport=tcp
aaa://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
aaas://host.abc.com;transport=tcp
aaas://host.abc.com;protocol=diameter
Enumerated Enumerated
Enumerated is derived from the Integer32 AVP Base Format. This Enumerated is derived from the Integer32 AVP Base Format. This
contains a list of valid values and their interpretation and is contains a list of valid values and their interpretation and is
described in the Diameter application introducing the AVP. described in the Diameter application introducing the AVP.
IPFilterRule IPFilterRule
The IPFilterRule format is derived from the OctetString AVP The IPFilterRule format is derived from the OctetString AVP
Base Format. It uses the UTF-8 encoding and has the same Base Format. It uses the UTF-8 encoding and has the same
requirements as the UTF8String. Packets may be filtered based requirements as the UTF8String. Packets may be filtered based
on the following information that is associated with it: on the following information that is associated with it:
Direction (in or out) Direction (in or out)
Source and destination IP address (possibly masked) Source and destination IP address (possibly masked)
Protocol Protocol
Source and destination port (lists or ranges) Source and destination port (lists or ranges)
TCP flags TCP flags
IP fragment flag IP fragment flag
IP options IP options
ICMP types ICMP types
Rules for the appropriate direction are evaluated in order, Rules for the appropriate direction are evaluated in order,
with the first matched rule terminating the evaluation. Each with the first matched rule terminating the evaluation. Each
packet is evaluated once. If no rule matches, the packet is packet is evaluated once. If no rule matches, the packet is
dropped if the last rule evaluated was a permit, and passed if dropped if the last rule evaluated was a permit, and passed if
the last rule was a deny. the last rule was a deny.
IPFilterRule filters MUST follow the format: IPFilterRule filters MUST follow the format:
action dir proto from src to dst [options] action dir proto from src to dst [options]
action permit - Allow packets that match the rule. action permit - Allow packets that match the rule.
deny - Drop packets that match the rule. deny - Drop packets that match the rule.
skipping to change at page 37, line 22 skipping to change at page 40, line 4
action permit - Allow packets that match the rule. action permit - Allow packets that match the rule.
deny - Drop packets that match the rule. deny - Drop packets that match the rule.
dir "in" is from the terminal, "out" is to the dir "in" is from the terminal, "out" is to the
terminal. terminal.
proto An IP protocol specified by number. The "ip" proto An IP protocol specified by number. The "ip"
keyword means any protocol will match. keyword means any protocol will match.
src and dst <address/mask> [ports] src and dst <address/mask> [ports]
The <address/mask> may be specified as: The <address/mask> may be specified as:
ipno An IPv4 or IPv6 number in dotted- ipno An IPv4 or IPv6 number in dotted-
quad or canonical IPv6 form. Only quad or canonical IPv6 form. Only
this exact IP number will match the this exact IP number will match the
rule. rule.
ipno/bits An IP number as above with a mask ipno/bits An IP number as above with a mask
width of the form 1.2.3.4/24. In width of the form 1.2.3.4/24. In
this case all IP numbers from this case all IP numbers from
1.2.3.0 to 1.2.3.255 will match. 1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the The bit width MUST be valid for the
IP version and the IP number MUST IP version and the IP number MUST
NOT have bits set beyond the mask. NOT have bits set beyond the mask.
The sense of the match can be inverted by The sense of the match can be inverted by
preceding an address with the not modifier, preceding an address with the not modifier (!),
causing all other addresses to be matched causing all other addresses to be matched
instead. This does not affect the selection of instead. This does not affect the selection of
port numbers. port numbers.
The keyword "any" is 0.0.0.0/0 or the IPv6 The keyword "any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned" is the equivalent. The keyword "assigned" is the
address or set of addresses assigned to the address or set of addresses assigned to the
terminal. The first rule SHOULD be "deny in terminal. The first rule SHOULD be "deny in
ip !assigned". ip !assigned".
With the TCP, UDP and SCTP protocols, optional With the TCP, UDP and SCTP protocols, optional
ports may be specified as: ports may be specified as:
{port|port-port}[,port[,...]] {port|port-port}[,ports[,...]]
The `-' notation specifies a range of ports The `-' notation specifies a range of ports
(including boundaries). (including boundaries).
Fragmented packets which have a non-zero offset Fragmented packets that have a non-zero offset
(i.e. not the first fragment) will never match (i.e. not the first fragment) will never match
a rule which has one or more port a rule that has one or more port
specifications. See the frag option for specifications. See the frag option for
details on matching fragmented packets. details on matching fragmented packets.
options: options:
frag Match if the packet is a fragment and this is not frag Match if the packet is a fragment and this is not
the first fragment of the datagram. frag may not the first fragment of the datagram. frag may not
be used in conjunction with either tcpflags or be used in conjunction with either tcpflags or
TCP/UDP port specifications. TCP/UDP port specifications.
ipoptions spec ipoptions spec
skipping to change at page 39, line 7 skipping to change at page 41, line 36
setup TCP packets only. Match packets that have the SYN setup TCP packets only. Match packets that have the SYN
bit set but no ACK bit. bit set but no ACK bit.
tcpflags spec tcpflags spec
TCP packets only. Match if the TCP header TCP packets only. Match if the TCP header
contains the comma separated list of flags contains the comma separated list of flags
specified in spec. The supported TCP flags are: specified in spec. The supported TCP flags are:
fin, syn, rst, psh, ack and urg. The absence of a fin, syn, rst, psh, ack and urg. The absence of a
particular flag may be denoted with a `!'. A rule particular flag may be denoted with a `!'. A rule
which contains a tcpflags specification can never that contains a tcpflags specification can never
match a fragmented packet which has a non-zero match a fragmented packet that has a non-zero
offset. See the frag option for details on offset. See the frag option for details on
matching fragmented packets. matching fragmented packets.
icmptypes types icmptypes types
ICMP packets only. Match if the ICMP type is in ICMP packets only. Match if the ICMP type is in
the list types. The list may be specified as any the list types. The list may be specified as any
combination of ranges or individual types combination of ranges or individual types
separated by commas. The supported ICMP types separated by commas. The supported ICMP types
are: are:
skipping to change at page 40, line 9 skipping to change at page 42, line 39
metered based on the following information that is associated metered based on the following information that is associated
with it: with it:
Direction (in or out) Direction (in or out)
Source and destination IP address (possibly masked) Source and destination IP address (possibly masked)
Protocol Protocol
Source and destination port (lists or ranges) Source and destination port (lists or ranges)
DSCP values (no mask or range) DSCP values (no mask or range)
Rules for the appropriate direction are evaluated in order, Rules for the appropriate direction are evaluated in order,
with the first matched rule terminating the evaluation. Each with the first matched rule terminating the evaluation. Each
packet is evaluated once. If no rule matches, the packet is packet is evaluated once. If no rule matches, the packet is
treated as best effort. treated as best effort.
QoSFilterRule filters MUST follow the format: QoSFilterRule filters MUST follow the format:
action dir proto from src to dst [options] action dir proto from src to dst [options]
tag - Mark packet with a specific DSCP [49]. tag - Mark packet with a specific DSCP
The DSCP option MUST be included. [DIFFSERV]. The DSCP option MUST be
included.
meter - Meter traffic. The metering options meter - Meter traffic. The metering options
MUST be included. MUST be included.
dir "in" is from the terminal, "out" is to the dir "in" is from the terminal, "out" is to the
terminal. terminal.
proto An IP protocol specified by number. The "ip" proto An IP protocol specified by number. The "ip"
keyword means any protocol will match. keyword means any protocol will match.
src and dst <address/mask> [ports] src and dst <address/mask> [ports]
skipping to change at page 40, line 44 skipping to change at page 43, line 27
rule. rule.
ipno/bits An IP number as above with a mask ipno/bits An IP number as above with a mask
width of the form 1.2.3.4/24. In width of the form 1.2.3.4/24. In
this case all IP numbers from this case all IP numbers from
1.2.3.0 to 1.2.3.255 will match. 1.2.3.0 to 1.2.3.255 will match.
The bit width MUST be valid for the The bit width MUST be valid for the
IP version and the IP number MUST IP version and the IP number MUST
NOT have bits set beyond the mask. NOT have bits set beyond the mask.
The sense of the match can be inverted by The sense of the match can be inverted by
preceding an address with the not modifier, preceding an address with the not modifier (!),
causing all other addresses to be matched causing all other addresses to be matched
instead. This does not affect the selection of instead. This does not affect the selection of
port numbers. port numbers.
The keyword "any" is 0.0.0.0/0 or the IPv6 The keyword "any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned" is the equivalent. The keyword "assigned" is the
address or set of addresses assigned to the address or set of addresses assigned to the
terminal. The first rule SHOULD be "deny in terminal. The first rule SHOULD be "deny in
ip !assigned". ip !assigned".
With the TCP, UDP and SCTP protocols, optional With the TCP, UDP and SCTP protocols, optional
ports may be specified as: ports may be specified as:
{port|port-port}[,port[,...]] {port|port-port}[,ports[,...]]
The `-' notation specifies a range of ports The `-' notation specifies a range of ports
(including boundaries). (including boundaries).
options: options:
DSCP <color> DSCP <color>
color values as defined in [49]. Exact matching color values as defined in [DIFFSERV]. Exact
of DSCP values is required (no masks or ranges). matching of DSCP values is required (no masks or
the "deny" can replace the color_under or ranges).
color_over values in the meter action for rate-
dependent packet drop.
metering <rate> <color_under> <color_over> metering <rate> <color_under> <color_over>
The metering option provides Assured Forwarding, The metering option provides Assured Forwarding,
as defined in [50], and MUST be present if the as defined in [DIFFSERVAF], and MUST be present
action is set to meter. The rate option is the if the action is set to meter. The rate option is
throughput, in bits per second, which is used by the throughput, in bits per second, which is used
the access device to mark packets. Traffic above by the access device to mark packets. Traffic
the rate is marked with the color_over codepoint, above the rate is marked with the color_over
while traffic under the rate is marked with the codepoint, while traffic under the rate is marked
color_under codepoint. The color_under and with the color_under codepoint. The color_under
color_over options contain the drop preferences, and color_over options contain the drop
and MUST conform to the recommended codepoint preferences, and MUST conform to the recommended
keywords described in [50] (e.g. AF13). codepoint keywords described in [DIFFSERVAF]
(e.g. AF13).
The metering option also supports the strict The metering option also supports the strict
limit on traffic required by Expedited limit on traffic required by Expedited
Forwarding, as defined in [51]. The color_over Forwarding, as defined in [DIFFSERVEF]. The
option may contain the keyword "drop" to prevent color_over option may contain the keyword "drop"
forwarding of traffic that exceeds the rate to prevent forwarding of traffic that exceeds the
parameter. rate parameter.
The rule syntax is a modified subset of ipfw(8) from FreeBSD, The rule syntax is a modified subset of ipfw(8) from FreeBSD,
and the ipfw.c code may provide a useful base for and the ipfw.c code may provide a useful base for
implementations. implementations.
4.5 Grouped AVP Values 4.5 Grouped AVP Values
The Diameter protocol allows AVP values of type 'Grouped.' This The Diameter protocol allows AVP values of type 'Grouped.' This
implies that the Data field is actually a sequence of AVPs. It is 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, 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 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 same padding requirements as non-Grouped AVPs, as defined in section
4.0. 4.0.
The AVP Code numbering space of all AVPs included in a Grouped AVP is 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 the same as for non-grouped AVPs. Further, if any of the AVPs
encapsulated within a Grouped AVP has the 'M' (mandatory) bit set, encapsulated within a Grouped AVP has the 'M' (mandatory) bit set,
the Grouped AVP itself MUST also include the 'M' bit set. the Grouped AVP itself MUST also include the 'M' bit set.
Every Grouped AVP defined MUST include a corresponding grammar, using Every Grouped AVP defined MUST include a corresponding grammar, using
ABNF [31] (with modifications), as defined below. ABNF [ABNF] (with modifications), as defined below.
avp-def = name "::=" avp avp-def = name "::=" avp
name-fmt = ALPHA *(ALPHA / DIGIT / "-") name-fmt = ALPHA *(ALPHA / DIGIT / "-")
name = name-fmt name = name-fmt
; The name has to be the name of an AVP, ; The name has to be the name of an AVP,
; defined in the base or extended Diameter ; defined in the base or extended Diameter
; specifications. ; specifications.
skipping to change at page 43, line 34 skipping to change at page 46, line 15
; specifications. ; specifications.
avp-name = avp-spec | "AVP" avp-name = avp-spec | "AVP"
; The string "AVP" stands for *any* arbitrary ; The string "AVP" stands for *any* arbitrary
; AVP Name, which does not conflict with the ; AVP Name, which does not conflict with the
; required or fixed position AVPs defined in ; required or fixed position AVPs defined in
; the command code definition. ; the command code definition.
4.5.1 Example AVP with a Grouped Data type 4.5.1 Example AVP with a Grouped Data type
The Example AVP (AVP Code 999999) is of type Grouped and is used to 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 clarify how Grouped AVP values work. The Grouped Data field has the
following ABNF grammar: following ABNF grammar:
Example-AVP ::= < AVP Header: 999999 > Example-AVP ::= < AVP Header: 999999 >
{ Origin-Host } { Origin-Host }
1*{ Session-Id } 1*{ Session-Id }
*[ AVP ] *[ AVP ]
An Example AVP with Grouped Data follows. An Example-AVP with Grouped Data follows.
The Origin-Host AVP is required. In this case: The Origin-Host AVP is required. In this case:
Origin-Host = "example.com". Origin-Host = "abc.com".
One or more Session-Ids must follow. Here there are two: One or more Session-Ids must follow. Here there are two:
Session-Id = Session-Id =
"grump.example.com:33041;23432;893;0AF3B81" "grump.abc.com:33041;23432;893;0AF3B81"
Session-Id = Session-Id =
"grump.example.com:33054;23561;2358;0AF3B82" "grump.abc.com:33054;23561;2358;0AF3B82"
optional AVPs included are optional AVPs included are
Recovery-Policy = <binary> Recovery-Policy = <binary>
2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119 cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
skipping to change at page 45, line 50 skipping to change at page 48, line 50
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
. . . . . .
+-------+-------+-------+-------+-------+-------+-------+-------+ +-------+-------+-------+-------+-------+-------+-------+-------+
464 | 0x41 |Padding|Padding|Padding| 464 | 0x41 |Padding|Padding|Padding|
+-------+-------+-------+-------+ +-------+-------+-------+-------+
4.6 Diameter Base Protocol AVPs 4.6 Diameter Base Protocol AVPs
The following table describes the Diameter AVPs defined in the base The following table describes the Diameter AVPs defined in the base
protocol, their AVP Code values, types, possible flag values and protocol, their AVP Code values, types, possible flag values and
whether the AVP MAY be encrypted. whether the AVP MAY be encrypted. For the originator of a Diameter
message, "MAY Encr" means that if a message containing that AVP is
to be sent via a proxy/agent then the message MUST NOT be sent
unless there is a DSA between the originator and the recipient OR
the originator has locally trusted configuration that indicates that
CMS need not be used.
Due to space constraints, the short form DiamIdent is used to Due to space constraints, the short form DiamIdent is used to
represent DiameterIdentity. represent DiameterIdentity.
+---------------------+ +---------------------+
| AVP Flag rules | | AVP Flag rules |
|----+-----+----+-----|----+ |----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY | AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----| -----------------------------------------|----+-----+----+-----|----|
Accounting- 482 9.8.2 Unsigned32 | M | P | | V | Y | Accounting- 482 9.8.2 Unsigned32 | M | P | | V | Y |
Interim-Interval | | | | | | Interim-Interval | | | | | |
Accounting- 483 9.8.7 Unsigned32 | M | P | | V | Y |
Realtime-Required | | | | | |
Accounting- 50 9.8.5 UTF8String | M | P | | V | Y | Accounting- 50 9.8.5 UTF8String | M | P | | V | Y |
Multi-Session-Id | | | | | | Multi-Session-Id | | | | | |
Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y | Accounting- 485 9.8.3 Unsigned32 | M | P | | V | Y |
Record-Number | | | | | | Record-Number | | | | | |
Accounting- 480 9.8.1 Enumerated | M | P | | V | Y | Accounting- 480 9.8.1 Enumerated | M | P | | V | Y |
Record-Type | | | | | | Record-Type | | | | | |
Accounting- 44 9.8.4 OctetString| M | P | | V | Y | Accounting- 44 9.8.4 OctetString| M | P | | V | Y |
RADIUS-Session-Id | | | | | | RADIUS-Session-Id | | | | | |
Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y | Accounting- 287 9.8.6 Unsigned64 | M | P | | V | Y |
Sub-Session-Id | | | | | | Sub-Session-Id | | | | | |
skipping to change at page 46, line 44 skipping to change at page 50, line 44
Period | | | | | | Period | | | | | |
Auth-Session- 277 8.11 Enumerated | M | P | | V | N | Auth-Session- 277 8.11 Enumerated | M | P | | V | N |
State | | | | | | State | | | | | |
Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N | Re-Auth-Request- 285 8.12 Enumerated | M | P | | V | N |
Type | | | | | | Type | | | | | |
Class 25 8.20 OctetString| M | P | | V | Y | Class 25 8.20 OctetString| M | P | | V | Y |
Destination-Host 293 6.5 DiamIdent | M | P | | V | N | Destination-Host 293 6.5 DiamIdent | M | P | | V | N |
Destination- 283 6.6 UTF8String | M | P | | V | N | Destination- 283 6.6 UTF8String | M | P | | V | N |
Realm | | | | | | Realm | | | | | |
Disconnect-Cause 273 5.4.3 Enumerated | M | P | | V | N | Disconnect-Cause 273 5.4.3 Enumerated | M | P | | V | N |
Error-Message 281 7.3 OctetString| | P | | V | N | Error-Message 281 7.3 OctetString| | P | | V,M | N |
Error-Reporting- 294 7.4 UTF8String | | P | | V | N | Error-Reporting- 294 7.4 UTF8String | | P | | V,M | N |
Host | | | | | | Host | | | | | |
Failed-AVP 279 7.5 Grouped | M | P | | V | N | Failed-AVP 279 7.5 Grouped | M | P | | V | N |
Firmware- 267 5.3.4 Unsigned32 | | P | | V,M | N | Firmware- 267 5.3.4 Unsigned32 | | | |P,V,M| N |
Revision | | | | | | Revision | | | | | |
Host-IP-Address 257 5.3.5 IPAddress | M | P | | V | N | Host-IP-Address 257 5.3.5 IPAddress | M | P | | V | N |
-----------------------------------------|----+-----+----+-----|----| -----------------------------------------|----+-----+----+-----|----|
+---------------------+ +---------------------+
| AVP Flag rules | | AVP Flag rules |
|----+-----+----+-----|----+ |----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY | AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----| -----------------------------------------|----+-----+----+-----|----|
Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y | Multi-Round- 272 8.19 Unsigned32 | M | P | | V | Y |
Time-Out | | | | | | Time-Out | | | | | |
Origin-Host 264 6.3 DiamIdent | M | P | | V | N | Origin-Host 264 6.3 DiamIdent | M | P | | V | N |
Origin-Realm 296 6.4 UTF8String | M | P | | V | N | Origin-Realm 296 6.4 UTF8String | M | P | | V | N |
Origin-State-Id 278 8.16 Unsigned32 | M | P | | V | N | Origin-State-Id 278 8.16 Unsigned32 | M | P | | V | N |
Product-Name 269 5.3.7 UTF8String | | P | | V | N | Product-Name 269 5.3.7 UTF8String | | | |P,V,M| N |
Proxy-Host 280 6.7.3 IPAddress | M | | | P,V | N | Proxy-Host 280 6.7.3 IPAddress | M | | | P,V | N |
Proxy-Info 284 6.7.2 Grouped | M | | | P,V | N | Proxy-Info 284 6.7.2 Grouped | M | | | P,V | N |
Proxy-State 33 6.7.4 OctetString| M | | | P,V | N | Proxy-State 33 6.7.4 OctetString| M | | | P,V | N |
Redirect-Host 292 6.11 DiamIdent | M | | | V | N | Redirect-Host 292 6.11 DiamURI | M | P | | V | N |
Redirect-Host- 261 6.12 Enumerated | M | P | | V | N | Redirect-Host- 261 6.12 Enumerated | M | P | | V | N |
Usage | | | | | | Usage | | | | | |
Redirect-Max- 262 6.13 Unsigned32 | M | P | | V | N | Redirect-Max- 262 6.13 Unsigned32 | M | P | | V | N |
Cache-Time | | | | | | Cache-Time | | | | | |
Result-Code 268 7.1 Unsigned32 | M | P | | V | N | Result-Code 268 7.1 Unsigned32 | M | P | | V | N |
Route-Record 282 6.7.1 DiamIdent | M | | | P,V | N | Route-Record 282 6.7.1 DiamIdent | M | | | P,V | N |
Session-Id 263 8.8 UTF8String | M | P | | V | Y | Session-Id 263 8.8 UTF8String | M | P | | V | Y |
Session-Timeout 27 8.13 Unsigned32 | M | P | | V | N | Session-Timeout 27 8.13 Unsigned32 | M | P | | V | N |
Session-Binding 270 8.17 Unsigned32 | M | P | | V | Y | Session-Binding 270 8.17 Unsigned32 | M | P | | V | Y |
Session-Server- 271 8.18 Enumerated | M | P | | V | Y | Session-Server- 271 8.18 Enumerated | M | P | | V | Y |
skipping to change at page 48, line 17 skipping to change at page 52, line 17
connections, if it is deemed necessary. Typically, all messages for a connections, if it is deemed necessary. Typically, all messages for a
realm are sent to the primary peer, but in the event that failover realm are sent to the primary peer, but in the event that failover
procedures are invoked, any pending requests are sent to the procedures are invoked, any pending requests are sent to the
secondary peer. However, implementations are free to load balance secondary peer. However, implementations are free to load balance
requests between a set of peers. requests between a set of peers.
Note that a given peer MAY act as a primary for a given realm, while Note that a given peer MAY act as a primary for a given realm, while
acting as a secondary for another realm. acting as a secondary for another realm.
When a peer is deemed suspect, which could occur for various reasons, When a peer is deemed suspect, which could occur for various reasons,
including not receiving a DWA within an alloted timeframe, no new including not receiving a DWA within an allotted timeframe, no new
requests should be forwarded to the peer, but failover procedures are requests should be forwarded to the peer, but failover procedures are
not invoked. When an active peer is moved to this mode, additional not invoked. When an active peer is moved to this mode, additional
connections SHOULD be established to ensure that the necessary number connections SHOULD be established to ensure that the necessary number
of active connections exists. of active connections exists.
There are two ways that a peer is removed from the suspect peer list: There are two ways that a peer is removed from the suspect peer list:
1. The peer is no longer reachable, causing the transport 1. The peer is no longer reachable, causing the transport
connection to be shutdown. The peer is moved to the closed connection to be shutdown. The peer is moved to the closed
state. state.
2. Three watchdog messages are exchanged with accepted round trip 2. Three watchdog messages are exchanged with accepted round trip
skipping to change at page 48, line 40 skipping to change at page 52, line 40
In the event the peer being removed is either the primary or In the event the peer being removed is either the primary or
secondary, an alternate peer SHOULD replace the deleted peer, and secondary, an alternate peer SHOULD replace the deleted peer, and
assume the role of either primary or secondary. assume the role of either primary or secondary.
5.2 Diameter Peer Discovery 5.2 Diameter Peer Discovery
Allowing for dynamic Diameter agent discovery will make it possible Allowing for dynamic Diameter agent discovery will make it possible
for simpler and more robust deployment of Diameter services. In for simpler and more robust deployment of Diameter services. In
order to promote interoperable implementations of Diameter peer order to promote interoperable implementations of Diameter peer
discovery, the following mechanisms are described. These are based discovery, the following mechanisms are described. These are based
on existing IETF standards. on existing IETF standards. The first option (manual configuration)
MUST be supported by all DIAMETER nodes, while the latter two options
(SRVLOC and DNS) MAY be supported.
There are two cases where Diameter peer discovery may be performed. There are two cases where Diameter peer discovery may be performed.
The first is when a Diameter client needs to discover a first-hop 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 Diameter agent. The second case is when a Diameter agent needs to
discover another agent - for further handling of a Diameter discover another agent - for further handling of a Diameter
operation. In both cases, the following 'search order' is operation. In both cases, the following 'search order' is
recommended: recommended:
1. The Diameter implementation consults its list of static 1. The Diameter implementation consults its list of static
(manual) configured Diameter agent locations. These will be (manual) configured Diameter agent locations. These will be
used if they exist and respond. used if they exist and respond.
2. The Diameter implementation uses SLPv2 [28] to discover 2. The Diameter implementation uses SLPv2 [SLP] to discover
Diameter services. The Diameter service template [32] is Diameter services. The Diameter service template [TEMPLATE] is
included in Appendix A. It is recommended that SLPv2 security included in Appendix A. It is recommended that SLPv2 security
be deployed (this requires distributing keys to SLPv2 agents). be deployed (this requires distributing keys to SLPv2 agents).
This is discussed further in Appendix A. This is discussed further in Appendix A.
SLPv2 will allow Diameter implementations to discover the SLPv2 will allow Diameter implementations to discover the
location of Diameter agents in the local site, as well as their location of Diameter agents in the local site, as well as their
characteristics. Diameter agents with specific capabilities characteristics. Diameter agents with specific capabilities
(say support for the Mobile IP application) can be requested, (say support for the Mobile IP application) can be requested,
and only those will be discovered. and only those will be discovered.
3. The Diameter implementation uses DNS to request the SRV RR [33] 3. The Diameter implementation performs a NAPTR query for a server
for the '_diameter._sctp' and/or '_diameter._tcp' server in a in a particular realm. The Diameter implementation has to know
particular realm. The Diameter implementation has to know in in advance which realm to look for a Diameter agent in. This
advance which realm to look for a Diameter agent in. This
could be deduced, for example, from the 'realm' in a NAI that a could be deduced, for example, from the 'realm' in a NAI that a
Diameter implementation needed to perform a Diameter operation Diameter implementation needed to perform a Diameter operation
on. on.
3.1 If the destination address is a numeric IP address, the 3.1 The services relevant for the task of transport protocol
requestor contacts the peer at the given address and the selection are those with NAPTR service fields with values
port number specified in the SRV record or, if not "AAA+D2x" and "AAAS+D2X", where x is a letter that
specified, the default port (TBD). corresponds to a transport protocol supported by the domain.
This specification defines D2T for TCP and D2S for SCTP. We
also establish an IANA registry for NAPTR service name to
transport protocol mappings.
3.2 The results of the query or queries are merged and ordered These NAPTR records provide a mapping from a domain, to the
based on priority. Then, the searching technique outlined in SRV record for contacting a server with the specific
[46] is used to select servers in order. The requestor transport protocol in the NAPTR services field. The resource
attempts to contact each peer in the order listed, at the record will contain an empty regular expression and a
port number specified in the SRV record. If none of the replacement value, which is the SRV record for that
servers can be contacted, the requestor gives up. If there particular transport protocol. If the server supports
are no SRV records, DNS address records are used, as multiple transport protocols, there will be multiple NAPTR
described below. records, each with a different service value. As per RFC
2915 [NAPTR], the client discards any records whose services
fields are not applicable. For the purposes of this
specification, several rules are defined.
3.3 If there are no SRV records, the requestor queries the DNS 3.2 First, a client resolving a AAAS URI MUST discard any
server for address records for the destination address services that do not contain "AAAS" as the protocol in the
'_diameter._sctp'.realm or '_diameter._tcp'.realm. Address service field. The converse is not true, however. A client
records include A RR's, AAAA RR's, A6 RR's or other similar resolving an AAA URI SHOULD retain records with "AAAS" as
records, chosen according to the requestor's network the protocol, if the client supports TLS. Second, a client
protocol capabilities. MUST discard any service fields that identify a resolution
service whose value is not "D2X", for values of X that
indicate transport protocols supported by the client. The
NAPTR processing as described in RFC 2915 will result in
discovery of the most preferred transport protocol of the
server that is supported by the client, as well as an SRV
record for the server. It will also allow the client to
discover if TLS is available and its preference for its
usage.
The domain suffixes in the NAPTR replacement field SHOULD
match the domain of the original query. It is not necessary
for the domain suffixes in the NAPTR replacement field to
match the domain of the original query.
3.3 If no NAPTR records are found, the requester queries for
those address records for the destination address,
'_diameters._sctp'.realm or '_diameters._tcp'.realm when
using TLS or '_diameter._sctp'.realm or
'_diameter._tcp'.realm when not using TLS. Address records
include A RR's, AAAA 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 If the DNS server returns no address records, the requestor
gives up. If there are address records, the same rules as in gives up.
step 3.2 apply.
Requestors MUST NOT cache query results except according to the For NAPTR records with AAAS protocol fields, if the server is
rules in [33]. Diameter allows AAA peers to protect the using a site certificate, the domain name in the query and the
integrity and privacy of communication as well as to perform domain name in the replacement field MUST both be valid based
end-point authentication. Still, it is prudent to employ DNS on the site certificate handed out by the server in the TLS
Security as a precaution when using DNS SRV RRs to look up the exchange. Similarly, the domain name in the SRV query and the
location of a Diameter agent [34, 35, 36]. domain name in the target in the SRV record MUST both be valid
based on the same site certificate. Otherwise, an attacker
could modify the DNS records to contain replacement values in a
different domain, and the client could not validate that this
was the desired behavior, or the result of an attack.
A dynamically discovered peer causes an entry in the Peer Table (see A dynamically discovered peer causes an entry in the Peer Table (see
section 2.7) to be created. Note that entries created via DNS MUST section 2.7) to be created. Note that entries created via DNS MUST
expire (or be refreshed) within the DNS TTL. If a peer is discovered expire (or be refreshed) within the DNS TTL. If a peer is discovered
outside of the local realm, a routing table entry (see Section 2.8) outside of the local realm, a routing table entry (see Section 2.8)
for the peer's realm is created. The routing table entry's expiration for the peer's realm is created. The routing table entry's expiration
MUST match the peer's expiration value. MUST match the peer's expiration value.
5.3 Capabilities Exchange 5.3 Capabilities Exchange
skipping to change at page 50, line 31 skipping to change at page 55, line 14
state machine (see section 5.6). This message allows the discovery of state machine (see section 5.6). This message allows the discovery of
a peer's identity and its capabilities (protocol version number, a peer's identity and its capabilities (protocol version number,
supported Diameter applications, etc.) supported Diameter applications, etc.)
The receiver only issues commands to its peers that have advertised The receiver only issues commands to its peers that have advertised
support for the Diameter application that defines the command. A support for the Diameter application that defines the command. A
Diameter node MUST cache the supported applications in order to Diameter node MUST cache the supported applications in order to
ensure that unrecognized commands and/or AVPs are not unnecessarily ensure that unrecognized commands and/or AVPs are not unnecessarily
sent to a peer. sent to a peer.
A receiver of a Capabilities-Exchange-Req (CER) message which does A receiver of a Capabilities-Exchange-Req (CER) message that does not
not have any applications in common with the sender MUST return a have any applications in common with the sender MUST return a
Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to Capabilities-Exchange-Answer (CEA) with the Result-Code AVP set to
DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport
layer connection. Note that receiving a CER or CEA from a peer layer connection. Note that receiving a CER or CEA from a peer
advertising itself as a Relay (see section 2.5) MUST be interpreted advertising itself as a Relay (see section 2.5) MUST be interpreted
as having common applications with the peer. as having common applications with the peer.
CERs received from unknown peers MAY be silently discarded, or a CEA CERs received from unknown peers MAY be silently discarded, or a CEA
MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER. MAY be issued with the Result-Code AVP set to DIAMETER_UNKNOWN_PEER.
In both cases, the transport connection is closed. If the local In both cases, the transport connection is closed. If the local
policy permits receiving CERs from unknown hosts, a successful CEA policy permits receiving CERs from unknown hosts, a successful CEA
skipping to change at page 51, line 22 skipping to change at page 56, line 5
advertised support for the application (or has advertised the Relay advertised support for the application (or has advertised the Relay
Application Identifier). Application Identifier).
5.3.1 Capabilities-Exchange-Request 5.3.1 Capabilities-Exchange-Request
The Capabilities-Exchange-Request (CER), indicated by the Command- The Capabilities-Exchange-Request (CER), indicated by the Command-
Code set to 257 and the Command Flags' 'R' bit set, is sent to Code set to 257 and the Command Flags' 'R' bit set, is sent to
exchange local capabilities. Upon detection of a transport failure, exchange local capabilities. Upon detection of a transport failure,
this message MUST NOT be sent to an alternate peer. this message MUST NOT be sent to an alternate peer.
When Diameter is run over SCTP [26], which allows for connections to When Diameter is run over SCTP [SCTP], which allows for connections
span multiple interfaces, hence multiple IP addresses, the to span multiple interfaces, hence, multiple IP addresses, the
Capabilities-Exchange-Request message MUST contain one Host-IP- Capabilities-Exchange-Request message MUST contain one Host-IP-
Address AVP for each potential IP address that MAY be locally used Address AVP for each potential IP address that MAY be locally used
when transmitting Diameter messages. when transmitting Diameter messages.
Message Format Message Format
<CER> ::= < Diameter Header: 257, REQ > <CER> ::= < Diameter Header: 257, REQ >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
1* { Host-IP-Address } 1* { Host-IP-Address }
skipping to change at page 52, line 5 skipping to change at page 56, line 33
* [ Vendor-Specific-Application-Id ] * [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ] [ Firmware-Revision ]
* [ AVP ] * [ AVP ]
5.3.2 Capabilities-Exchange-Answer 5.3.2 Capabilities-Exchange-Answer
The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code The Capabilities-Exchange-Answer (CEA), indicated by the Command-Code
set to 257 and the Command Flags' 'R' bit cleared, is sent in set to 257 and the Command Flags' 'R' bit cleared, is sent in
response to a CER message. response to a CER message.
When Diameter is run over SCTP [26], which allows for connections to When Diameter is run over SCTP [SCTP], which allows connections to
span multiple interfaces, hence multiple IP addresses, the span multiple interfaces, hence, multiple IP addresses, the
Capabilities-Exchange-Answer message MUST contain one Host-IP-Address Capabilities-Exchange-Answer message MUST contain one Host-IP-Address
AVP for each potential IP address that MAY be locally used when AVP for each potential IP address that MAY be locally used when
transmitting Diameter messages. transmitting Diameter messages.
Message Format Message Format
<CEA> ::= < Diameter Header: 257 > <CEA> ::= < Diameter Header: 257 >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
1* { Host-IP-Address } 1* { Host-IP-Address }
{ Vendor-Id } { Vendor-Id }
{ Product-Name } { Product-Name }
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Message ] [ Error-Message ]
* [ Failed-AVP ] * [ Failed-AVP ]
* [ Supported-Vendor-Id ] * [ Supported-Vendor-Id ]
* [ Auth-Application-Id ] * [ Auth-Application-Id ]
* [ Acct-Application-Id ] * [ Acct-Application-Id ]
[ Vendor-Specific-Application-Id ] * [ Vendor-Specific-Application-Id ]
[ Firmware-Revision ] [ Firmware-Revision ]
* [ AVP ] * [ AVP ]
5.3.3 Vendor-Id AVP 5.3.3 Vendor-Id AVP
The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains The Vendor-Id AVP (AVP Code 266) is of type Unsigned32 and contains
the IANA "SMI Network Management Private Enterprise Codes" [2] value the IANA "SMI Network Management Private Enterprise Codes" [ASSIGNNO]
assigned to the vendor of the Diameter device. value assigned to the vendor of the Diameter device. In combination
with the Supported-Vendor-Id AVP (section 5.3.6), this MAY be used in
In combination with the Supported-Vendor-Id AVP (section 5.3.6), this order to know which vendor specific attributes may be sent to the
MAY be used in order to know which vendor specific attributes may be peer. It is also envisioned that the combination of the Vendor-Id,
sent to the peer. It is also envisioned that the combination of the Product-Name (section 5.3.7) and the Firmware-Revision (section
Vendor-Id, Product-Name (section 5.3.7) and the Firmware-Revision 5.3.4) AVPs MAY provide very useful debugging information.
(section 5.3.4) AVPs MAY provide very useful debugging information.
A Vendor-Id value of zero in the CER or CEA messages is reserved and A Vendor-Id value of zero in the CER or CEA messages is reserved and
indicates that the Diameter peer is in the experimental or concept indicates that the Diameter peer is in the experimental or concept
stage and that an IANA Private Enterprise Number has yet to be stage and that an IANA Private Enterprise Number has yet to be
obtained by the implementor. obtained by the implementer.
5.3.4 Firmware-Revision AVP 5.3.4 Firmware-Revision AVP
The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is
used to inform a Diameter peer of the firmware revision of the used to inform a Diameter peer of the firmware revision of the
issuing device. issuing device.
For devices that do not have a firmware revision (general purpose For devices that do not have a firmware revision (general purpose
computers running Diameter software modules, for instance), the computers running Diameter software modules, for instance), the
revision of the Diameter software module may be reported instead. revision of the Diameter software module may be reported instead.
skipping to change at page 53, line 11 skipping to change at page 58, line 4
The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is The Firmware-Revision AVP (AVP Code 267) is of type Unsigned32 and is
used to inform a Diameter peer of the firmware revision of the used to inform a Diameter peer of the firmware revision of the
issuing device. issuing device.
For devices that do not have a firmware revision (general purpose For devices that do not have a firmware revision (general purpose
computers running Diameter software modules, for instance), the computers running Diameter software modules, for instance), the
revision of the Diameter software module may be reported instead. revision of the Diameter software module may be reported instead.
5.3.5 Host-IP-Address AVP 5.3.5 Host-IP-Address AVP
The Host-IP-Address AVP (AVP Code 257) is of type IPAddress and is The Host-IP-Address AVP (AVP Code 257) is of type IPAddress and is
used to inform a Diameter peer of the sender's IP address. All used to inform a Diameter peer of the sender's IP address. All source
source addresses that a Diameter node expects to use with SCTP [26] addresses that a Diameter node expects to use with SCTP [SCTP] MUST
MUST be advertised in the CER and CEA messages by including a Host- be advertised in the CER and CEA messages by including a Host-IP-
IP-Address AVP for each address. This AVP MUST ONLY be used in the Address AVP for each address. This AVP MUST ONLY be used in the CER
CER and CEA messages. and CEA messages.
5.3.6 Supported-Vendor-Id AVP 5.3.6 Supported-Vendor-Id AVP
The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and The Supported-Vendor-Id AVP (AVP Code 265) is of type Unsigned32 and
contains the IANA "SMI Network Management Private Enterprise Codes" contains the IANA "SMI Network Management Private Enterprise Codes"
[2] value assigned to a vendor other than the device vendor. This is [ASSIGN NO] value assigned to a vendor other than the device vendor.
used in the CER and CEA messages in order to inform the peer that the This is used in the CER and CEA messages in order to inform the peer
sender supports a subset of the vendor-specific commands and/or AVPs that the sender supports a subset of the vendor-specific commands
defined by the vendor identified in this AVP. and/or AVPs defined by the vendor identified in this AVP.
5.3.7 Product-Name AVP 5.3.7 Product-Name AVP
The Product-Name AVP (AVP Code 269) is of type UTF8String, and The Product-Name AVP (AVP Code 269) is of type UTF8String, and
contains the vendor assigned name for the product. The Product-Name contains the vendor assigned name for the product. The Product-Name
AVP SHOULD remain constant across firmware revisions for the same AVP SHOULD remain constant across firmware revisions for the same
product. product.
5.4 Disconnecting Peer connections 5.4 Disconnecting Peer connections
skipping to change at page 54, line 8 skipping to change at page 58, line 44
was a result of either a shortage of internal resources, or simply was a result of either a shortage of internal resources, or simply
that the node in question has no intentions of forwarding any that the node in question has no intentions of forwarding any
Diameter messages to the peer in the foreseeable future, a periodic Diameter messages to the peer in the foreseeable future, a periodic
connection request would not be welcomed. The Disconnection-Reason connection request would not be welcomed. The Disconnection-Reason
AVP contains the reason the Diameter node issued the Disconnect-Peer- AVP contains the reason the Diameter node issued the Disconnect-Peer-
Request message. Request message.
The Disconnect-Peer-Request message is used by a Diameter node to The Disconnect-Peer-Request message is used by a Diameter node to
inform its peer of its intent to disconnect the transport layer, and inform its peer of its intent to disconnect the transport layer, and
that the peer shouldn't reconnect unless it has a valid reason to do that the peer shouldn't reconnect unless it has a valid reason to do
so (e.g. message to be forwarded). Upon receipt of the message, the so (e.g. message to be forwarded). Upon receipt of the message, the
Disconnect-Peer-Answer is returned, which SHOULD contain an error if Disconnect-Peer-Answer is returned, which SHOULD contain an error if
messages have recently be forwarded, and are likely in flight, which messages have recently be forwarded, and are likely in flight, which
would otherwise cause a race condition. would otherwise cause a race condition.
The receiver of the Disconnect-Peer-Answer initiates the transport The receiver of the Disconnect-Peer-Answer initiates the transport
disconnect. disconnect.
5.4.1 Disconnect-Peer-Request 5.4.1 Disconnect-Peer-Request
The Disconnect-Peer-Request (DPR), indicated by the Command-Code set The Disconnect-Peer-Request (DPR), indicated by the Command-Code set
skipping to change at page 54, line 49 skipping to change at page 59, line 41
<DPA> ::= < Diameter Header: 282 > <DPA> ::= < Diameter Header: 282 >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ Error-Message ] [ Error-Message ]
* [ Failed-AVP ] * [ Failed-AVP ]
5.4.3 Disconnect-Cause AVP 5.4.3 Disconnect-Cause AVP
The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A The Disconnect-Cause AVP (AVP Code 273) is of type Enumerated. A
Diameter node MUST include this AVP in the Disconnect-Peer-Request Diameter node MUST include this AVP in the Disconnect-Peer-Request
message to inform the peer of the reason for its intention to message to inform the peer of the reason for its intention to
shutdown the transport connection. The following values are shutdown the transport connection. The following values are
supported: supported:
REBOOTING 0 REBOOTING 0
A scheduled reboot is imminent. A scheduled reboot is imminent.
BUSY 1 BUSY 1
The peer's internal resources are constrained, and it has The peer's internal resources are constrained, and it has
determined that the transport connection needs to be shutdown. determined that the transport connection needs to be shutdown.
DO_NOT_WANT_TO_TALK_TO_YOU 2 DO_NOT_WANT_TO_TALK_TO_YOU 2
The peer has determined that it does not see a need for the The peer has determined that it does not see a need for the
transport connection to exist, since it does not expect any transport connection to exist, since it does not expect any
messages to be exchanged in the foreseeable future. messages to be exchanged in the near future.
ELECTION_LOST 3
The peer has determined that it has lost the election process
and has therefore disconnected the transport connection.
5.5 Transport Failure Detection 5.5 Transport Failure Detection
Given the nature of the Diameter protocol, it is recommended that Given the nature of the Diameter protocol, it is recommended that
transport failures be detected as soon as possible. Detecting such transport failures be detected as soon as possible. Detecting such
failures will minimize the occurrence of messages sent to unavailable failures will minimize the occurrence of messages sent to unavailable
agents, resulting in unnecessary delays, and will provide better agents, resulting in unnecessary delays, and will provide better
failover performance. The Device-Watchdog-Request and Device- failover performance. The Device-Watchdog-Request and Device-
Watchdog-Answer messages, defined in this section, are used to pro- Watchdog-Answer messages, defined in this section, are used to pro-
actively detect transport failures. actively detect transport failures.
5.5.1 Device-Watchdog-Request 5.5.1 Device-Watchdog-Request
The Device-Watchdog-Request (DWR), indicated by the Command-Code set The Device-Watchdog-Request (DWR), indicated by the Command-Code set
to 280 and the Command Flags' 'R' bit set, is sent to a peer when no to 280 and the Command Flags' 'R' bit set, is sent to a peer when no
traffic has been exchanged between two peers (see Section 5.5.3). traffic has been exchanged between two peers (see Section 5.5.3).
Upon detection of a transport failure, this message MUST NOT be sent Upon detection of a transport failure, this message MUST NOT be sent
to an alternate peer. to an alternate peer.
skipping to change at page 56, line 12 skipping to change at page 61, line 4
{ Origin-Realm } { Origin-Realm }
[ Origin-State-Id ] [ Origin-State-Id ]
5.5.2 Device-Watchdog-Answer 5.5.2 Device-Watchdog-Answer
The Device-Watchdog-Answer (DWA), indicated by the Command-Code set 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 280 and the Command Flags' 'R' bit cleared, is sent as a response
to the Device-Watchdog-Request message. to the Device-Watchdog-Request message.
Message Format Message Format
<DWA> ::= < Diameter Header: 280 > <DWA> ::= < Diameter Header: 280 >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ Error-Message ] [ Error-Message ]
* [ Failed-AVP ] * [ Failed-AVP ]
[ Original-State-Id ] [ Original-State-Id ]
5.5.3 Transport Failure Algorithm 5.5.3 Transport Failure Algorithm
The transport failure algorithm is defined in [52]. All Diameter The transport failure algorithm is defined in [AAATRANS]. All
implementations MUST support the algorithm defined in the Diameter implementations MUST support the algorithm defined in the
specification in order to be compliant to the Diameter base protocol. specification in order to be compliant to the Diameter base protocol.
5.5.4 Failover/Failback Procedures 5.5.4 Failover/Failback Procedures
In the event that a transport failure is detected with a peer, it is In the event that a transport failure is detected with a peer, it is
necessary for all pending request messages to be forwarded to an necessary for all pending request messages to be forwarded to an
alternate agent, if possible. This is commonly referred to as alternate agent, if possible. This is commonly referred to as
failover. failover.
In order for a Diameter node to perform failover procedures, it is In order for a Diameter node to perform failover procedures, it is
skipping to change at page 57, line 14 skipping to change at page 62, line 7
used to identify duplicate messages. used to identify duplicate messages.
As described in section 2.1, a connection request should be As described in section 2.1, a connection request should be
periodically attempted with the failed peer in order to re-establish periodically attempted with the failed peer in order to re-establish
the transport connection. Once a connection has been successfully the transport connection. Once a connection has been successfully
established, messages can once again be forwarded to the peer. This established, messages can once again be forwarded to the peer. This
is commonly referred to as failback. is commonly referred to as failback.
5.6 Peer State Machine 5.6 Peer State Machine
This section contains a finite state machine, that MUST be observed This section contains a finite state machine that MUST be observed by
by all Diameter implementations. Each Diameter node MUST follow the all Diameter implementations. Each Diameter node MUST follow the
state machine described below when communicating with each peer. state machine described below when communicating with each peer.
Multiple actions are separated by commas, and may continue on Multiple actions are separated by commas, and may continue on
succeeding lines as space requires. Similarly, state and next state succeeding lines, as space requires. Similarly, state and next state
may also span multiple lines as space requires. may also span multiple lines, as space requires.
This state machine is closely coupled with the state machine This state machine is closely coupled with the state machine
described in [52], which is used to establish transport connections described in [AAATRANS], which is used to open, close, failover,
with Diameter peers. When the state machine below requests a probe, and reopen transport connections. Note in particular that
transport connection with the peer, the state machine in [52] is [AAATRANS] requires the use of watchdog messages to probe
invoked. Once the connection has been established, the state machine connections. For Diameter, DWR and DWA messages are to be used.
in this section is followed.
There may be at most one transport connection between any two peers
over which Diameter messages may be passed. This state machine is
intended to handle both the simple case, in which one peer initiates
a connection to the 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 port on which a connection
is initiated from MUST NOT be the port Diameter listens for incoming
connections.
I- is used to represent the initiator (connecting) connection, while I- is used to represent the initiator (connecting) connection, while
the R- is used to represent the responder (listening) connection. The the R- is used to represent the responder (listening) connection. The
lack of a prefix indicates that the event or action is the same lack of a prefix indicates that the event or action is the same
regardless of the connection on which the event occurred. regardless of the connection on which the event occurred.
The stable states that a state machine may be in are Closed, I-Open The stable states that a state machine may be in are Closed, I-Open
and R-Open; all other states are intermediate. Note that I-Open and and R-Open; all other states are intermediate. Note that I-Open and
R-Open are equivalent except for whether the initiator or responder R-Open are equivalent except for whether the initiator or responder
transport connection is used for communication. transport connection is used for communication.
skipping to change at page 59, line 7 skipping to change at page 63, line 36
Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open Wait-Returns Win-Election I-Disc,R-Snd-CEA R-Open
I-Peer-Disc I-Disc, R-Open I-Peer-Disc I-Disc, R-Open
R-Snd-CEA R-Snd-CEA
I-Rcv-CEA R-Disc I-Open I-Rcv-CEA R-Disc I-Open
R-Peer-Disc R-Disc Wait-I-CEA R-Peer-Disc R-Disc Wait-I-CEA
R-Conn-CER R-Reject Wait-Returns R-Conn-CER R-Reject Wait-Returns
Timeout Error Closed Timeout Error Closed
R-Open Send-Message R-Snd-Message R-Open R-Open Send-Message R-Snd-Message R-Open
R-Rcv-Message Process R-Open R-Rcv-Message Process R-Open
WatchDog-Timer R-Snd-DWR R-Open
R-Rcv-DWR Process-DWR, R-Open R-Rcv-DWR Process-DWR, R-Open
R-Snd-DWA R-Snd-DWA
R-Rcv-DWA Process-DWA R-Open R-Rcv-DWA Process-DWA R-Open
R-Conn-CER R-Snd-CEA R-Open R-Conn-CER R-Snd-CEA R-Open
R-Reject R-Reject
Stop R-Snd-DPR Closing Stop R-Snd-DPR Closing
R-Rcv-DPR R-Snd-DPA, Closed R-Rcv-DPR R-Snd-DPA, Closed
R-Disc R-Disc
R-Peer-Disc R-Disc Closed R-Peer-Disc R-Disc Closed
R-Rcv-CER R-Snd-CEA R-Open R-Rcv-CER R-Snd-CEA R-Open
R-Rcv-CEA Process-CEA R-Open R-Rcv-CEA Process-CEA R-Open
I-Open Send-Message I-Snd-Message I-Open I-Open Send-Message I-Snd-Message I-Open
I-Rcv-Message Process I-Open I-Rcv-Message Process I-Open
WatchDog-Timer I-Snd-DWR I-Open
I-Rcv-DWR Process-DWR, I-Open I-Rcv-DWR Process-DWR, I-Open
I-Snd-DWA I-Snd-DWA
I-Rcv-DWA Process-DWA I-Open I-Rcv-DWA Process-DWA I-Open
R-Conn-CER R-Reject I-Open R-Conn-CER R-Reject I-Open
Stop I-Snd-DPR Closing Stop I-Snd-DPR Closing
I-Rcv-DPR I-Snd-DPA, Closed I-Rcv-DPR I-Snd-DPA, Closed
I-Disc I-Disc
I-Peer-Disc I-Disc Closed I-Peer-Disc I-Disc Closed
I-Rcv-CER I-Snd-CEA I-Open I-Rcv-CER I-Snd-CEA I-Open
I-Rcv-CEA Process-CEA I-Open I-Rcv-CEA Process-CEA I-Open
skipping to change at page 59, line 44 skipping to change at page 64, line 22
Closing I-Rcv-DPA I-Disc Closed Closing I-Rcv-DPA I-Disc Closed
R-Rcv-DPA R-Disc Closed R-Rcv-DPA R-Disc Closed
Timeout Error Closed Timeout Error Closed
I-Peer-Disc I-Disc Closed I-Peer-Disc I-Disc Closed
R-Peer-Disc R-Disc Closed R-Peer-Disc R-Disc Closed
5.6.1 Incoming connections 5.6.1 Incoming connections
When a connection request is received from a Diameter peer, it is When a connection request is received from a Diameter peer, it is
not, in the general case, possible to know the identity of that peer not, in the general case, possible to know the identity of that peer
until a CER is received from it. This is because the identity of a until a CER is received from it. This is because host and port
Diameter peer is determined by host and port; and the source port of determine the identity of a Diameter peer; and the source port of an
an incoming connection is arbitrary. Upon receipt of CER, the incoming connection is arbitrary. Upon receipt of CER, the identity
identity of the connecting peer can be uniquely determined from of the connecting peer can be uniquely determined from Origin-Host.
Origin-Host.
For this reason, a Diameter peer must employ logic separate from the For this reason, a Diameter peer must employ logic separate from the
state machine to receive connection requests, accept them, and await state machine to receive connection requests, accept them, and await
CER. Once CER arrives on a new connection, the Origin-Host which CER. Once CER arrives on a new connection, the Origin-Host that
identifies the peer is used to locate the state machine associated identifies the peer is used to locate the state machine associated
with that peer, and the new connection and CER are passed to the with that peer, and the new connection and CER are passed to the
state machine as an R-Conn-CER event. state machine as an R-Conn-CER event.
The logic that handles incoming connections SHOULD close and discard The logic that handles incoming connections SHOULD close and discard
the connection if any message other than CER arrives, or if an the connection if any message other than CER arrives, or if an
implementation-defined timeout occurs prior to receipt of CER. implementation-defined timeout occurs prior to receipt of CER.
Because handling of incoming connections up to and including receipt Because handling of incoming connections up to and including receipt
of CER requires logic separate from that of any individual state of CER requires logic, separate from that of any individual state
machine associated with a particular peer, it is described separately machine associated with a particular peer, it is described separately
in this section rather than in the state machine above. in this section rather than in the state machine above.
5.6.2 Events 5.6.2 Events
Transitions and actions in the automaton are caused by events. In Transitions and actions in the automaton are caused by events. In
this section we will ignore the -I and -R prefix, since the actual this section, we will ignore the -I and -R prefix, since the actual
event would be identical, but would occur on one of two possible event would be identical, but would occur on one of two possible
connections. connections.
Start The Diameter application has signaled that a Start The Diameter application has signaled that a
connection should be initiated with the peer. The connection should be initiated with the peer.
state machine in [52] is to be initiated to create
a transport connection.
R-Conn-CER An acknowledgement is received from the state R-Conn-CER An acknowledgement is received stating that the
machine in [52] stating that the transport transport connection has been established, and the
connection has been established, and the associated associated CER has arrived.
CER has arrived.
Rcv-Conn-Ack A positive acknowledgement is received from the Rcv-Conn-Ack A positive acknowledgement is received confirming
state machine in [52] confirming that the transport that the transport connection is established.
connection is established.
Rcv-Conn-Nack A negative acknowledgement was received from the Rcv-Conn-Nack A negative acknowledgement was received stating
state machine in [52] stating that the transport that the transport connection was not established.
connection was not established.
Timeout An application-defined timer has expired while Timeout An application-defined timer has expired while
waiting for some event. waiting for some event.
Rcv-CER A CER message from the peer was received. Rcv-CER A CER message from the peer was received.
Rcv-CEA A CEA message from the peer was received. Rcv-CEA A CEA message from the peer was received.
Rcv-Non-CEA A message other than CEA from the peer was Rcv-Non-CEA A message other than CEA from the peer was
received. received.
skipping to change at page 61, line 18 skipping to change at page 65, line 40
Rcv-DPR A DPR message from the peer was received. Rcv-DPR A DPR message from the peer was received.
Rcv-DPA A DPA message from the peer was received. Rcv-DPA A DPA message from the peer was received.
Win-Election An election was held, and the local node was the Win-Election An election was held, and the local node was the
winner. winner.
Send-Message A message is to be sent. Send-Message A message is to be sent.
Rcv-Message A message other than CER, CEA, DWR, or DWA was Rcv-Message A message other than CER, CEA, DPR, DPA, DWR, or
received. DWA was received.
WatchDog-Timer The Watchdog timer expired, indicating that a DWR
message is to be sent to the peer.
Rcv-DWR A DWR message was received.
Rcv-DWA A DWA message was received.
Stop The Diameter application has signaled that a Stop The Diameter application has signaled that a
connection should be terminated (e.g., on system connection should be terminated (e.g., on system
shutdown). shutdown).
5.6.3 Actions 5.6.3 Actions
Actions in the automaton are caused by events and typically indicate Actions in the automaton are caused by events and typically indicate
the transmission of packets and/or an action to be taken on the the transmission of packets and/or an action to be taken on the
connection. In this section we will ignore the I- and R- prefix, connection. In this section we will ignore the I- and R- prefix,
since the actual action would be identical, but would occur on one of since the actual action would be identical, but would occur on one of
two possible connections. two possible connections.
Snd-Conn-Req A transport connection is initiated with the peer. Snd-Conn-Req A transport connection is initiated with the peer.
The state machine in [52] is used to establish the
transport connection with the peer.
Accept The incoming connection associated with the R-Conn- Accept The incoming connection associated with the R-Conn-
CER is accepted as the responder connection. CER is accepted as the responder connection.
Reject The incoming connection associated with the R-Conn- Reject The incoming connection associated with the R-Conn-
CER is disconnected. CER is disconnected.
Process-CER The CER associated with the R-Conn-CER is Process-CER The CER associated with the R-Conn-CER is
processed. processed.
Snd-Conn-Ack an acknowledgement is received from the state Snd-Conn-Ack an acknowledgement is received confirming that the
machine in [52] confirming that the transport transport connection is established.
connection is established.
Snd-CER A CER message is sent to the peer. Snd-CER A CER message is sent to the peer.
Snd-CEA A CEA message is sent to the peer. Snd-CEA A CEA message is sent to the peer.
Cleanup If necessary, the connection is shutdown, and any Cleanup If necessary, the connection is shutdown, and any
local resources are freed. local resources are freed.
Error The transport layer connection is disconnected, Error The transport layer connection is disconnected,
either politely or abortively, in response to an either politely or abortively, in response to an
skipping to change at page 63, line 6 skipping to change at page 67, line 17
Process A message is serviced. Process A message is serviced.
5.6.4 The Election Process 5.6.4 The Election Process
The election is performed on the responder. The responder compares The election is performed on the responder. The responder compares
the Origin-Host received in the CER sent by its peer with its own the Origin-Host received in the CER sent by its peer with its own
Origin-Host. If the local Diameter entity's Origin-Host is higher Origin-Host. If the local Diameter entity's Origin-Host is higher
than the peer's, a Win-Election event is issued locally. than the peer's, a Win-Election event is issued locally.
The comparison proceeds by considering the shorter OctetString to be The comparison proceeds by considering the shorter OctetString to be
null-padded to the length of the longer, then performing an octet by null-padded to the length of the longer, then performing an octet-by-
octet unsigned comparison with the first octet being most octet unsigned comparison with the first octet being most
significant. Hanging octets are assumed to have value 0x80, but significant. Hanging octets are assumed to have value 0x80, but
dimpled octets are ignored. dimpled octets are ignored.
6.0 Diameter message processing 6.0 Diameter message processing
This section describes how Diameter requests and answers are created This section describes how Diameter requests and answers are created
and processed. and processed.
6.1 Diameter request routing overview 6.1 Diameter request routing overview
A request is sent towards its final destination using a combination A request is sent towards its final destination using a combination
of the Destination-Realm and Destination-Host AVPs, in one of these of the Destination-Realm and Destination-Host AVPs, in one of these
three combinations: three combinations:
- a request that is not proxiable (such as CER) MUST NOT contain - a request that is not able to be proxied (such as CER) MUST NOT
either Destination-Realm or Destination-Host AVPs. contain either Destination-Realm or Destination-Host AVPs.
- a request that needs to be sent to a home server serving a - a request that needs to be sent to a home server serving a
specific realm, but not to a specific server (such as the first specific realm, but not to a specific server (such as the first
request of a series of round-trips), MUST contain a Destination- request of a series of round-trips), MUST contain a Destination-
Realm AVP, but MUST NOT contain a Destination-Host AVP. Realm AVP, but MUST NOT contain a Destination-Host AVP.
- a request that needs to be sent to a specific home server among - a request that needs to be sent to a specific home server among
those serving a given realm, MUST contain both the Destination- those serving a given realm, MUST contain both the Destination-
Realm and Destination-Host AVPs. Realm and Destination-Host AVPs.
The Destination-Host AVP is used as described above when the The Destination-Host AVP is used as described above when the
destination of the request is fixed, which includes: destination of the request is fixed, which includes:
skipping to change at page 63, line 47 skipping to change at page 68, line 12
- Server initiated messages that MUST be received by a specific - Server initiated messages that MUST be received by a specific
Diameter client (e.g. access device), such as the Abort-Session- Diameter client (e.g. access device), such as the Abort-Session-
Request message, which is used to request that a particular Request message, which is used to request that a particular
user's session be terminated. user's session be terminated.
Note that an agent can forward a request to a host described in the Note that an agent can forward a request to a host described in the
Destination-Host AVP only if the host in question is included in its Destination-Host AVP only if the host in question is included in its
peer table (see section 2.7). Otherwise, the request is routed based peer table (see section 2.7). Otherwise, the request is routed based
on the Destination-Realm only (see sections 6.1.6). on the Destination-Realm only (see sections 6.1.6).
The Destination-Realm AVP MUST be present if the message is routable. The Destination-Realm AVP MUST be present if the message is
A message that MUST NOT be relayed, proxied or redirected MUST NOT proxiable. Proxiable request messages MUST also contain either an
include the Destination-Realm in its ABNF. The value of the Acct-Application-Id AVP or an Auth-Application-Id AVP. A message that
Destination-Realm AVP MAY be extracted from the User-Name AVP, or MUST NOT be relayed, proxied or redirected MUST NOT include the
other application-specific methods. Destination-Realm in its ABNF. The value of the Destination-Realm AVP
MAY be extracted from the User-Name AVP, or other application-
specific methods.
When a message is received, the message is processed in the following When a message is received, the message is processed in the following
order: order:
1. If the message is destined for the local host, the procedures 1. If the message is destined for the local host, the procedures
listed in section 6.1.4 are followed. listed in section 6.1.4 are followed.
2. If the message is intended for a Diameter peer with whom the 2. If the message is intended for a Diameter peer with whom the
local host is able to directly communicate, the procedures local host is able to directly communicate, the procedures
listed in section 6.1.5 are followed. This is known as Request listed in section 6.1.5 are followed. This is known as Request
Forwarding. Forwarding.
3. The procedures listed in section 6.1.6 are followed, which is 3. The procedures listed in section 6.1.6 are followed, which is
known as Request Routing. known as Request Routing.
4. If none of the above are successful, an answer is returned with 4. If none of the above is successful, an answer is returned with
the Result-Code set to DIAMETER_UNABLE_TO_DELIVER. the Result-Code set to DIAMETER_UNABLE_TO_DELIVER.
For routing of Diameter messages to work within an administrative For routing of Diameter messages to work within an administrative
domain, all Diameter nodes within the realm MUST be peers. If domain, all Diameter nodes within the realm MUST be peers. If
intermediate nodes are desired (see Figure 5), the destination node intermediate nodes are desired (see Figure 5), the destination node
MUST be in a subrealm and routes to that subrealm MUST exist in the MUST be in a subrealm and routes to that subrealm MUST exist in the
routing table on the sending node and all intermediate nodes. Figure routing table on the sending node and all intermediate nodes. Figure
5 shows an example of a hierarchical network that requires the use of 5 shows an example of a hierarchical network that requires the use of
subrealms. In such a network, routing must be performed with longest subrealms. In such a network, routing must be performed with longest
match from right. match from right.
skipping to change at page 64, line 44 skipping to change at page 69, line 21
+-------+ +-------+ +-------+ +-------+
+-------------+ +--------------+ +-------------+ +--------------+ +-------------+ +--------------+ +-------------+ +--------------+
| eng.abc.com | | acct.abc.com | | mkt.abc.com | | exec.abc.com | | eng.abc.com | | acct.abc.com | | mkt.abc.com | | exec.abc.com |
+-------------+ +--------------+ +-------------+ +--------------+ +-------------+ +--------------+ +-------------+ +--------------+
Figure 5: Hierarchical administrative domain Figure 5: Hierarchical administrative domain
Note the processing rules contained in this section are intended to Note the processing rules contained in this section are intended to
be used as general guidelines to Diameter developers. Certain be used as general guidelines to Diameter developers. Certain
implementations MAY use different methods than the ones described implementations MAY use different methods than the ones described
here, and still be in compliance with the protocol specification. here, and still comply with the protocol specification.
6.1.1 Originating a Request 6.1.1 Originating a Request
When creating a request, in addition to any other procedures When creating a request, in addition to any other procedures
described in the application definition for that specific request, described in the application definition for that specific request,
the following procedures MUST be followed: the following procedures MUST be followed:
- the Command-Code should be set to the appropriate value - the Command-Code should be set to the appropriate value
- the 'R' bit should be set - the 'R' bit should be set
- the End-to-End Identifier should be set to a locally unique - the End-to-End Identifier should be set to a locally unique
value value
- the Origin-Host and Origin-Realm AVPs MUST be set to the - the Origin-Host and Origin-Realm AVPs MUST be set to the
appropriate values, used to identify the source of the message appropriate values, used to identify the source of the message
- the Destination-Host and Destination-Realm AVPs MUST be set to - the Destination-Host and Destination-Realm AVPs MUST be set to
the appropriate values as described in section 6.1. the appropriate values as described in section 6.1.
- either an Acct-Application-Id AVP or an Auth-Application-Id AVP
must be included if the request is proxiable.
6.1.2 Sending a Request 6.1.2 Sending a Request
When sending a request, either originated locally, or as the result When sending a request, originated either locally, or as the result
of a forwarding or routing operation, the following procedures MUST of a forwarding or routing operation, the following procedures MUST
be followed: be followed:
- the Hop-by-Hop Identifier should be set to a locally unique - the Hop-by-Hop Identifier should be set to a locally unique
value value
- The message should be saved in the list of pending requests. - The message should be saved in the list of pending requests.
Other actions to perform on the message based on the particular role Other actions to perform on the message based on the particular role
the agent is playing are described in the following sections. the agent is playing are described in the following sections.
6.1.3 Receiving Requests 6.1.3 Receiving Requests
skipping to change at page 66, line 4 skipping to change at page 70, line 27
- The Destination-Host AVP is not present, the Destination-Realm - The Destination-Host AVP is not present, the Destination-Realm
AVP contains a realm the server is configured to process AVP contains a realm the server is configured to process
locally, and the Diameter application is locally supported, or locally, and the Diameter application is locally supported, or
- Both the Destination-Host and the Destination-Realm are not - Both the Destination-Host and the Destination-Realm are not
present. present.
When a request is locally processed, the rules in section 6.2 should When a request is locally processed, the rules in section 6.2 should
be used to generate the corresponding answer. be used to generate the corresponding answer.
6.1.5 Request Forwarding 6.1.5 Request Forwarding
Request forwarding is done using the Diameter Peer Table. The Request forwarding is done using the Diameter Peer Table. The
Diameter peer table contains all of the peers that the local node is Diameter peer table contains all of the peers that the local node is
able to directly communicate with. able to directly communicate with.
When a request is received, and the host encoded in the Destination- When a request is received, and the host encoded in the Destination-
Host AVP is one that is present in the peer table, the message SHOULD Host AVP is one that is present in the peer table, the message SHOULD
be forwarded to the peer. be forwarded to the peer.
6.1.6 Request Routing 6.1.6 Request Routing
Diameter request message routing is done via realms. A Diameter Diameter request message routing is done via realms. A Diameter
message that is proxyable MUST include the target realm in the message that is able to be proxied MUST include the target realm in
Destination-Realm AVP. The realm MAY be retrieved from the User-Name the Destination-Realm AVP. The realm MAY be retrieved from the User-
AVP, which is in the form of a Network Access Identifier (NAI). The Name AVP, which is in the form of a Network Access Identifier (NAI).
realm portion of the NAI is inserted in the Destination-Realm AVP. The realm portion of the NAI is inserted in the Destination-Realm
AVP.
Diameter agents MAY have a list of locally supported realms, and MAY Diameter agents MAY have a list of locally supported realms, and MAY
have a list of externally supported realms. When a request is have a list of externally supported realms. When a request is
received that includes a realm that is not locally supported, the received that includes a realm that is not locally supported, the
message is routed to the peer configured in the Realm Routing Table message is routed to the peer configured in the Realm Routing Table
table (see section 2.8). table (see section 2.8).
6.1.7 Redirecting requests 6.1.7 Redirecting requests
When a redirect agent receives a request whose routing entry is set When a redirect agent receives a request whose routing entry is set
to REDIRECT, it MUST reply with an answer message with the 'E' bit to REDIRECT, it MUST reply with an answer message with the 'E' bit
set, while maintaining the Hop-by-Hop Identifier in the header, and set, while maintaining the Hop-by-Hop Identifier in the header, and
include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of include the Result-Code AVP to DIAMETER_REDIRECT_INDICATION. Each of
the servers associated with the routing entry are added in separate the servers associated with the routing entry are added in separate
Redirect-Host AVP. Redirect-Host AVP.
+------------------+ +------------------+
| Diameter | | Diameter |
| Redirect Agent | | Redirect Agent |
+------------------+ +------------------+
^ | 2. command + 'E' bit ^ | 2. command + 'E' bit
1. Request | | Result-Code = 1. Request | | Result-Code =
joe@xyz.com | | DIAMETER_REDIRECT_INDICATION + joe@xyz.com | | DIAMETER_REDIRECT_INDICATION +
| | Redirect-Host AVP(s) | | Redirect-Host AVP(s)
| v | v
+---------+ 3. Request +----------+ +---------+ 3. Request +----------+
| abc.net |------------->| xyz.net | | abc.net |------------->| xyz.net |
| Relay | | Diameter | | Relay | | Diameter |
| Agent |<-------------| Server | | Agent |<-------------| Server |
+---------+ 4. Answer +----------+ +---------+ 4. Answer +----------+
Figure 6: Diameter Redirect Agent Figure 6: Diameter Redirect Agent
Redirect agents MAY also include the certificate of the servers in Redirect agents MAY also include the certificate of the servers in
the Redirect-Host AVP(s). These certificates are encapsulated in a the Redirect-Host AVP(s). These certificates are encapsulated in a
CMS-Cert AVP [11]. AAA-Node-Cert AVP [CMS].
The receiver of the answer message with the 'E' bit set, and the The receiver of the answer message with the 'E' bit set, and the
Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by- Result-Code AVP set to DIAMETER_REDIRECT_INDICATION uses the hop-by-
hop field in the Diameter header to identify the request in the hop field in the Diameter header to identify the request in the
pending message queue (see Section 5.3) that is to be redirected. If pending message queue (see Section 5.3) that is to be redirected. If
no transport connection exists with the new agent, one is created, no transport connection exists with the new agent, one is created,
and the request is sent directly to it. and the request is sent directly to it.
6.1.8 Relaying and Proxying Requests 6.1.8 Relaying and Proxying Requests
A relay or proxy agent MUST append a Route-Record AVP to all requests A relay or proxy agent MUST append a Route-Record AVP to all requests
forwarded. The AVP contains the identity of the peer the request was forwarded. The AVP contains the identity of the peer the request was
received from. received from.
The Hop-by-Hop identifier in the request is saved, and replaced with The Hop-by-Hop identifier in the request is saved, and replaced with
skipping to change at page 69, line 25 skipping to change at page 73, line 34
If a relay or proxy agent receives an answer with a Result-Code AVP If a relay or proxy agent receives an answer with a Result-Code AVP
indicating a failure, it MUST NOT modify the contents of the AVP. Any indicating a failure, it MUST NOT modify the contents of the AVP. Any
additional local errors detected SHOULD be logged, but not reflected additional local errors detected SHOULD be logged, but not reflected
in the Result-Code AVP. If the agent receives an answer message with in the Result-Code AVP. If the agent receives an answer message with
a Result-Code AVP indicating success, and it wishes to modify the AVP a Result-Code AVP indicating success, and it wishes to modify the AVP
to indicate an error, it MUST modify the Result-Code AVP to contain to indicate an error, it MUST modify the Result-Code AVP to contain
the appropriate error in the message destined towards the access the appropriate error in the message destined towards the access
device as well as include the Error-Reporting-Host AVP and it MUST device as well as include the Error-Reporting-Host AVP and it MUST
issue an STR on behalf of the access device. issue an STR on behalf of the access device.
The agent MUST then send the answer to the host which it received the The agent MUST then send the answer to the host that it received the
original request from. original request from.
6.3 Origin-Host AVP 6.3 Origin-Host AVP
The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and The Origin-Host AVP (AVP Code 264) is of type DiameterIdentity, and
MUST be present in all Diameter messages. This AVP identifies the MUST be present in all Diameter messages. This AVP identifies the
endpoint which originated the Diameter message. Relay agents MUST NOT endpoint that originated the Diameter message. Relay agents MUST NOT
modify this AVP. modify this AVP.
The value of the Origin-Host AVP is guaranteed to be unique within a The value of the Origin-Host AVP is guaranteed to be unique within a
single host. single host.
Note that the Origin-Host AVP may resolve to more than one address as Note that the Origin-Host AVP may resolve to more than one address as
the Diameter peer may support more than one address. the Diameter peer may support more than one address.
This AVP SHOULD be placed as close to the Diameter header as This AVP SHOULD be placed as close to the Diameter header as
possible. possible.
skipping to change at page 70, line 28 skipping to change at page 74, line 39
possible. possible.
6.6 Destination-Realm AVP 6.6 Destination-Realm AVP
The Destination-Realm AVP (AVP Code 283) is of type UTF8String, and The Destination-Realm AVP (AVP Code 283) is of type UTF8String, and
contains the realm the message is to be routed to. The Destination- contains the realm the message is to be routed to. The Destination-
Realm AVP MUST NOT be present in Answer messages. Diameter Clients Realm AVP MUST NOT be present in Answer messages. Diameter Clients
insert the realm portion of the User-Name AVP. Diameter servers insert the realm portion of the User-Name AVP. Diameter servers
initiating a request message use the value of the Origin-Realm AVP initiating a request message use the value of the Origin-Realm AVP
from a previous message received from the intended target host from a previous message received from the intended target host
(unless it is known a priori). When present, the Destination-Realm (unless it is known a priori). When present, the Destination-Realm
AVP is used to perform message routing decisions. AVP is used to perform message routing decisions.
Request messages whose ABNF does not list the Destination-Realm AVP Request messages whose ABNF does not list the Destination-Realm AVP
as a mandatory AVP are inherently non-routable messages. as a mandatory AVP are inherently non-routable messages.
This AVP SHOULD be placed as close to the Diameter header as This AVP SHOULD be placed as close to the Diameter header as
possible. possible.
6.7 Routing AVPs 6.7 Routing AVPs
The AVPs defined in this section are Diameter AVPs used for routing The AVPs defined in this section are Diameter AVPs used for routing
purposes. These AVPs change as Diameter messages are processed by purposes. These AVPs change as Diameter messages are processed by
agents, and therefore MUST NOT be protected using the Diameter CMS agents, and therefore MUST NOT be protected using the Diameter CMS
Security application [11]. Security application [CMS].
6.7.1 Route-Record AVP 6.7.1 Route-Record AVP
The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The The Route-Record AVP (AVP Code 282) is of type DiameterIdentity. The
identity added in this AVP MUST be the same as the one received in identity added in this AVP MUST be the same as the one received in
the Origin-Host of the Capabilities Exchange message. the Origin-Host of the Capabilities Exchange message.
6.7.2 Proxy-Info AVP 6.7.2 Proxy-Info AVP
The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped The Proxy-Info AVP (AVP Code 284) is of type Grouped. The Grouped
Data field has the following ABNF grammar: Data field has the following ABNF grammar:
Proxy-Info ::= < AVP Header: 284 > Proxy-Info ::= < AVP Header: 284 >
{ Proxy-Host } { Proxy-Host }
skipping to change at page 72, line 29 skipping to change at page 76, line 39
AVP Format AVP Format
<Vendor-Specific-Application-Id> ::= < AVP Header: 260 > <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
1* [ Vendor-Id ] 1* [ Vendor-Id ]
0*1{ Auth-Application-Id } 0*1{ Auth-Application-Id }
0*1{ Acct-Application-Id } 0*1{ Acct-Application-Id }
6.11 Redirect-Host AVP 6.11 Redirect-Host AVP
The Redirect-Host AVP (AVP Code 292) is of type DiameterIdentity. The Redirect-Host AVP (AVP Code 292) is of type DiameterURI. This AVP
This AVP MUST be present if the answer message's 'E' bit is set and MUST be present if the answer message's 'E' bit is set and the
the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
Upon receiving the above, the receiving Diameter node SHOULD forward Upon receiving the above, the receiving Diameter node SHOULD forward
the request directly to the host identified in this AVP. The server the request directly to the host identified in this AVP. The server
contained in the Redirect-Host SHOULD be used for all messages contained in the Redirect-Host SHOULD be used for all messages
pertaining to this session. pertaining to this session.
6.12 Redirect-Host-Usage AVP 6.12 Redirect-Host-Usage AVP
The Redirect-Host-Usage AVP (AVP Code 261) is of type Enumerated. The 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 This AVP MAY be present in answer messages whose 'E' bit is set and
the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION. the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION.
When present, this AVP dictates how the routing entry resulting from When present, this AVP dictates how the routing entry resulting from
the Redirect-Host is to be used. The following values are supported: the Redirect-Host is to be used. The following values are supported:
DONT_CACHE 0 DONT_CACHE 0
The host specified in the Redirect-Host AVP should not be The host specified in the Redirect-Host AVP should not be
cached. This is the default value. cached. This is the default value.
skipping to change at page 73, line 29 skipping to change at page 77, line 38
ALL_APPLICATION 4 ALL_APPLICATION 4
All messages for the application requested MAY be sent to the All messages for the application requested MAY be sent to the
host specified in the Redirect-Host AVP. host specified in the Redirect-Host AVP.
ALL_HOST 5 ALL_HOST 5
All messages that would be sent to the host that generated the All messages that would be sent to the host that generated the
Redirect-Host MAY be sent to the host specified in the Redirect-Host MAY be sent to the host specified in the
Redirect-Host AVP. Redirect-Host AVP.
ALL_USER 6
All messages for the user requested MAY be sent to the host
specified in the Redirect-Host AVP.
6.13 Redirect-Max-Cache-Time AVP 6.13 Redirect-Max-Cache-Time AVP
The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32. The Redirect-Max-Cache-Time AVP (AVP Code 262) is of type Unsigned32.
This AVP MUST be present in answer messages whose 'E' bit is set, the This AVP MUST be present in answer messages whose 'E' bit is set, the
Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the Result-Code AVP is set to DIAMETER_REDIRECT_INDICATION and the
Redirect-Host-Usage AVP set to a non-zero value. Redirect-Host-Usage AVP set to a non-zero value.
This AVP contains the maximum number of seconds the peer and route This AVP contains the maximum number of seconds the peer and route
table entries, created as a result of the Redirect-Host, will be table entries, created as a result of the Redirect-Host, will be
cached. Note that once a host created due to a redirect indication is cached. Note that once a host created due to a redirect indication is
no longer reachable, any associated peer and routing table entries no longer reachable, any associated peer and routing table entries
MUST be deleted. MUST be deleted.
7.0 Error Handling 7.0 Error Handling
There are two different types of errors in Diameter; protocol and There are two different types of errors in Diameter; protocol and
applications. A protocol error is one that occurs at the base applications. A protocol error is one that occurs at the base
protocol level, and MAY require per hop attention (e.g. message protocol level, and MAY require per hop attention (e.g. message
routing error). Application errors, on the other hand, are generally routing error). Application errors, on the other hand, are generally
occur due to a problem with a function specified in a Diameter occur due to a problem with a function specified in a Diameter
application (e.g. user authentication, Missing AVP). application (e.g. user authentication, Missing AVP).
Result-Code AVP values that are used to report protocol errors MUST Result-Code AVP values that are used to report protocol errors MUST
only be present in answer messages whose 'E' bit is set. When a only be present in answer messages whose 'E' bit is set. When a
request message is received that causes a protocol error, an answer request message is received that causes a protocol error, an answer
message is returned with the 'E' bit set, and the Result-Code AVP is message is returned with the 'E' bit set, and the Result-Code AVP is
set to the appropriate protocol error value. As the answer is sent set to the appropriate protocol error value. As the answer is sent
back towards the originator of the request, each proxy or relay agent back towards the originator of the request, each proxy or relay agent
MAY take action on the message. MAY take action on the message.
skipping to change at page 76, line 9 skipping to change at page 80, line 26
7.1.1 Informational 7.1.1 Informational
Errors that fall within this category are used to inform the Errors that fall within this category are used to inform the
requester that a request could not be satisfied, and additional requester that a request could not be satisfied, and additional
action is required on its part before access is granted. action is required on its part before access is granted.
DIAMETER_MULTI_ROUND_AUTH 1001 DIAMETER_MULTI_ROUND_AUTH 1001
This informational error is returned by a Diameter server to This informational error is returned by a Diameter server to
inform the access device that the authentication mechanism inform the access device that the authentication mechanism
being used required multiple round trip, and a subsequent being used required multiple round trips, and a subsequent
request needs to be issued in order for access to be granted. request needs to be issued in order for access to be granted.
7.1.2 Success 7.1.2 Success
Errors that fall within the Success category are used to inform a Errors that fall within the Success category are used to inform a
peer that a request has been successfully completed. peer that a request has been successfully completed.
DIAMETER_SUCCESS 2001 DIAMETER_SUCCESS 2001
The Request was successfully completed. The Request was successfully completed.
skipping to change at page 78, line 4 skipping to change at page 82, line 22
The authentication process for the user failed, most likely due The authentication process for the user failed, most likely due
to an invalid password used by the user. Further attempts MUST to an invalid password used by the user. Further attempts MUST
only be tried after prompting the user for a new password. only be tried after prompting the user for a new password.
DIAMETER_OUT_OF_SPACE 4002 DIAMETER_OUT_OF_SPACE 4002
A Diameter node received the accounting request but was unable A Diameter node received the accounting request but was unable
to commit it to stable storage due to a temporary lack of to commit it to stable storage due to a temporary lack of
space. space.
7.1.5 Permanent Failures 7.1.5 Permanent Failures
Errors that fall within the permanent failures category are used to Errors that fall within the permanent failures category are used to
inform the peer that the request failed, and should not be attempted inform the peer that the request failed, and should not be attempted
again. again.
DIAMETER_AVP_UNSUPPORTED 5001 DIAMETER_AVP_UNSUPPORTED 5001
The peer received a message that contained an AVP that is not The peer received a message that contained an AVP that is not
recognized or supported and was marked with the Mandatory bit. recognized or supported and was marked with the Mandatory bit.
A Diameter message with this error MUST contain one or more A Diameter message with this error MUST contain one or more
Failed-AVP AVP containing the AVPs that caused the failure. Failed-AVP AVP containing the AVPs that caused the failure.
DIAMETER_UNKNOWN_SESSION_ID 5002 DIAMETER_UNKNOWN_SESSION_ID 5002
The request contained an unknown Session-Id. The request contained an unknown Session-Id.
DIAMETER_AUTHORIZATION_REJECTED 5003 DIAMETER_AUTHORIZATION_REJECTED 5003
A request was received for which the user could not be A request was received for which the user could not be
authorized. This error could occur if the service requested is authorized. This error could occur if the service requested is
not permitted to the user. not permitted to the user.
DIAMETER_INVALID_AVP_VALUE 5004 DIAMETER_INVALID_AVP_VALUE 5004
The request contained an AVP with an invalid value in its data The request contained an AVP with an invalid value in its data
portion. A Diameter message indicating this error MUST include portion. A Diameter message indicating this error MUST include
the offending AVPs within a Failed-AVP AVP. the offending AVPs within a Failed-AVP AVP.
DIAMETER_MISSING_AVP 5005 DIAMETER_MISSING_AVP 5005
The request did not contain an AVP that is required by the The request did not contain an AVP that is required by the
Command Code definition. If this value is sent in the Result- Command Code definition. If this value is sent in the Result-
skipping to change at page 79, line 13 skipping to change at page 83, line 32
offending AVP. offending AVP.
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009 DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5009
A message was received that included an AVP that appeared more A message was received that included an AVP that appeared more
often than permitted in the message definition. The Failed-AVP often than permitted in the message definition. The Failed-AVP
AVP MUST be included and contain a copy of the first instance AVP MUST be included and contain a copy of the first instance
of the offending AVP that exceeded the maximum number of of the offending AVP that exceeded the maximum number of
occurrences occurrences
DIAMETER_UNSUPPORTED_TRANSFORM 5010 DIAMETER_UNSUPPORTED_TRANSFORM 5010
A message was received that included an CMS-Data AVP [11] that A message was received that included a CMS-Data AVP [CMS] that
made use of an unsupported transform. made use of an unsupported transform.
DIAMETER_NO_COMMON_APPLICATION 5011 DIAMETER_NO_COMMON_APPLICATION 5011
This error is returned when a CER message is received, and This error is returned when a CER message is received, and
there are no common applications supported between the peer. there are no common applications supported between the peers.
DIAMETER_UNSUPPORTED_VERSION 5012 DIAMETER_UNSUPPORTED_VERSION 5012
This error is returned when a request was received, whose This error is returned when a request was received, whose
version number is unsupported. version number is unsupported.
DIAMETER_UNABLE_TO_COMPLY 5013 DIAMETER_UNABLE_TO_COMPLY 5013
This error is returned when a request is rejected for This error is returned when a request is rejected for
unspecified reasons. unspecified reasons.
DIAMETER_INVALID_BIT_IN_HEADER 5014 DIAMETER_INVALID_BIT_IN_HEADER 5014
skipping to change at page 79, line 50 skipping to change at page 84, line 21
DIAMETER_INVALID_AVP_BIT_COMBO 5017 DIAMETER_INVALID_AVP_BIT_COMBO 5017
The request contained an AVP with which is not allowed to have The request contained an AVP with which is not allowed to have
the given value in the AVP Flags field. A Diameter message the given value in the AVP Flags field. A Diameter message
indicating this error MUST include the offending AVPs within a indicating this error MUST include the offending AVPs within a
Failed-AVP AVP. Failed-AVP AVP.
7.2 Error Bit 7.2 Error Bit
The 'E' (Error Bit) in the Diameter header is set when the request The 'E' (Error Bit) in the Diameter header is set when the request
caused a protocol-related error (see section 7.1.3). A message with caused a protocol-related error (see section 7.1.3). A message with
the 'E' bit MUST NOT be sent as a response to an answer message. Note the 'E' bit MUST NOT be sent as a response to an answer message. Note
that a message with the 'E' bit set is still subjected to the that a message with the 'E' bit set is still subjected to the
processing rules defined in section 6.2. When set, the answer processing rules defined in section 6.2. When set, the answer message
message will not conform to the ABNF specification for the command, will not conform to the ABNF specification for the command, and will
and will instead conform to the following ABNF: instead conform to the following ABNF:
Message Format Message Format
<answer-message> ::= < Diameter Header: code, ERR [PXY] > <answer-message> ::= < Diameter Header: code, ERR [PXY] >
0*1< Session-Id > 0*1< Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Result-Code } { Result-Code }
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
skipping to change at page 80, line 36 skipping to change at page 85, line 9
7.3 Error-Message AVP 7.3 Error-Message AVP
The Error-Message AVP (AVP Code 281) is of type UTF8String. It MAY 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 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 Error-Message AVP is not intended to be useful in real-time, and
SHOULD NOT be expected to be parsed by network entities. SHOULD NOT be expected to be parsed by network entities.
7.4 Error-Reporting-Host AVP 7.4 Error-Reporting-Host AVP
The Error-Reporting-Host AVP (AVP Code 294) is of type The Error-Reporting-Host AVP (AVP Code 294) is of type
DiameterIdentity. This AVP contains the identity of the Diameter DiameterIdentity. This AVP contains the identity of the Diameter host
host that sent the Result-Code AVP to a value other than 2001 that sent the Result-Code AVP to a value other than 2001 (Success),
(Success), only if the host setting the Result-Code is different from only if the host setting the Result-Code is different from the one
the one encoded in the Origin-Host AVP. This AVP is intended to be encoded in the Origin-Host AVP. This AVP is intended to be used for
used for troubleshooting purposes, and MUST be set when the Result- troubleshooting purposes, and MUST be set when the Result-Code AVP
Code AVP indicates a failure. indicates a failure.
7.5 Failed-AVP AVP 7.5 Failed-AVP AVP
The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides The Failed-AVP AVP (AVP Code 279) is of type Grouped and provides
debugging information in cases where a request is rejected or not debugging information in cases where a request is rejected or not
fully processed due to erroneous information in a specific AVP. The fully processed due to erroneous information in a specific AVP. The
value of the Result-Code AVP will provide information on the reason value of the Result-Code AVP will provide information on the reason
for the Failed-AVP AVP. for the Failed-AVP AVP.
The possible reasons for this AVP are the presence of an improperly The possible reasons for this AVP are the presence of an improperly
constructed AVP, an unsupported or unrecognized AVP, an invalid AVP constructed AVP, an unsupported or unrecognized AVP, an invalid AVP
value, the omission of a required AVP, the presence of an explicitly value, the omission of a required AVP, the presence of an explicitly
excluded AVP (see tables in section 10.0), or the presence of two or excluded AVP (see tables in section 10.0), or the presence of two or
more occurrences of an AVP which is restricted to 0, 1, or 0-1 more occurrences of an AVP which is restricted to 0, 1, or 0-1
occurrences. occurrences.
A Diameter message MAY contain one Failed-AVP AVP, containing the A Diameter message MAY contain one Failed-AVP AVP, containing the
entire AVP that could not be processed successfully. If the failure entire AVP that could not be processed successfully. If the failure
reason is omission of a required AVP, an AVP with the missing AVP 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 code, the missing vendor id, and a zero filled payload of the minimum
required length for the omitted AVP will be added. required length for the omitted AVP will be added.
AVP Format AVP Format
<Failed-AVP> ::= < AVP Header: 279 > <Failed-AVP> ::= < AVP Header: 279 >
1* {AVP} 1* {AVP}
8.0 Diameter User Sessions 8.0 Diameter User Sessions
Diameter can provide two different type of services to applications. Diameter can provide two different types of services to applications.
The first involves authentication and authorization, and can The first involves authentication and authorization, and can
optionally make use of accounting. The second only makes use of optionally make use of accounting. The second only makes use of
accounting. accounting.
When a service makes use of the authentication and/or authorization When a service makes use of the authentication and/or authorization
portion of an application, and a user requests access to the network, portion of an application, and a user requests access to the network,
the Diameter client issues an auth request to its local server. The the Diameter client issues an auth request to its local server. The
auth request is defined in a service specific Diameter application auth request is defined in a service specific Diameter application
(e.g. NASREQ). The request contains a Session-Id AVP, which is used (e.g. NASREQ). The request contains a Session-Id AVP, which is used
in subsequent messages (e.g. subsequent authorization, accounting, in subsequent messages (e.g. subsequent authorization, accounting,
skipping to change at page 81, line 49 skipping to change at page 86, line 23
user session. user session.
When a Diameter server authorizes a user to use network resources for When a Diameter server authorizes a user to use network resources for
a finite amount of time, and it is willing to extend the a finite amount of time, and it is willing to extend the
authorization via a future request, it MUST add the Authorization- authorization via a future request, it MUST add the Authorization-
Lifetime AVP to the answer message. The Authorization-Lifetime AVP Lifetime AVP to the answer message. The Authorization-Lifetime AVP
defines the maximum number of seconds a user MAY make use of the defines the maximum number of seconds a user MAY make use of the
resources before another authorization request is expected by the resources before another authorization request is expected by the
server. The Auth-Grace-Period AVP contains the number of seconds server. The Auth-Grace-Period AVP contains the number of seconds
following the expiration of the Authorization-Lifetime, after which following the expiration of the Authorization-Lifetime, after which
the server will release an state information related to the user's the server will release all state information related to the user's
session. Note that if payment for services is expected by the serving session. Note that if payment for services is expected by the serving
realm from the user's home realm, the Authorization-Lifetime AVP, realm from the user's home realm, the Authorization-Lifetime AVP,
combined with the Auth-Grace-Period AVP, implies the maximum length combined with the Auth-Grace-Period AVP, implies the maximum length
the session the home realm is willing to be fiscally responsible for. of the session the home realm is willing to be fiscally responsible
Services provided past the expiration of the Authorization-Lifetime for. Services provided past the expiration of the Authorization-
and Auth-Grace-Period AVPs is the responsibility of the access Lifetime and Auth-Grace-Period AVPs is the responsibility of the
device. Of course, the actual cost of services rendered is clearly access device. Of course, the actual cost of services rendered is
outside the scope of the protocol. clearly outside the scope of the protocol.
An access device that does not expect to send a re-authorization or a An access device that does not expect to send a re-authorization or a
session termination request to the server MAY include the Auth- session termination request to the server MAY include the Auth-
Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint
to the server. If the server accepts the hint, it agrees that since to the server. If the server accepts the hint, it agrees that since
no session termination message will be received once service to the no session termination message will be received once service to the
user is terminated, it cannot maintain state for the session. If the user is terminated, it cannot maintain state for the session. If the
answer message from the server contains a different value in 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), Auth-Session-State AVP (or the default value if the AVP is absent),
the access device MUST follow the server's directives. Note that the the access device MUST follow the server's directives. Note that the
skipping to change at page 82, line 41 skipping to change at page 87, line 13
When a service only makes use of the Accounting portion of the When a service only makes use of the Accounting portion of the
Diameter protocol, even in combination with an application, the Diameter protocol, even in combination with an application, the
Session-Id is still used to identify user sessions. However, the Session-Id is still used to identify user sessions. However, the
session termination messages are not used, since a session is session termination messages are not used, since a session is
signaled as being terminated by issuing an accounting stop message. signaled as being terminated by issuing an accounting stop message.
8.1 Authorization Session State Machine 8.1 Authorization Session State Machine
This section contains a finite state machine, representing the life This section contains a finite state machine, representing the life
cycle of Diameter sessions, and MUST be observed by all Diameter cycle of Diameter sessions, and MUST be observed by all Diameter
implementations that makes use of the authentication and/or implementations that make use of the authentication and/or
authorization portion of a Diameter application. The term Service- authorization portion of a Diameter application. The term Service-
Specific below refers to a message defined in a Diameter application Specific below refers to a message defined in a Diameter application
(e.g. Mobile IP, NASREQ). (e.g. Mobile IP, NASREQ).
There are two different session state machines supported in the There are two different session state machines supported in the
Diameter base protocol. The first consists of a session in which the Diameter base protocol. The first consists of a session in which the
server is maintaining session state, indicated by the value of the server is maintaining session state, indicated by the value of the
Auth-Session-State AVP (or its absence). The second state machine is Auth-Session-State AVP (or its absence). The second state machine is
used when the server does not maintain session state. used when the server does not maintain session state.
skipping to change at page 84, line 26 skipping to change at page 88, line 47
Open Accounting message sent or process Open Open Accounting message sent or process Open
received received
Open Failed Service-specific Discon. Idle Open Failed Service-specific Discon. Idle
authorization answer user/device authorization answer user/device
received. received.
Open Session-Timeout Expires on send STR Discon Open Session-Timeout Expires on send STR Discon
Access Device Access Device
Open Home server wants to send ASR Discon Open Home server wants to send ASR Open
terminate the service terminate the service
Open ASA Received Cleanup Idle
with Result-Code
= UNKNOWN-SESSION-ID
Open ASA Received None Open
with Result-Code (ignore)
not = UNKNOWN-SESSION-ID
Open ASR Received send ASA, Discon Open ASR Received send ASA, Discon
STR STR
Open Authorization-Lifetime + send STR Discon Open Authorization-Lifetime + send STR Discon
Auth-Grace-Period expires on Auth-Grace-Period expires on
access device access device
Open Authorization-Lifetime (and Cleanup Discon Open Authorization-Lifetime (and Cleanup Discon
Auth-Grace-Period) expires Auth-Grace-Period) expires
on home server. on home server.
Open Session-Timeout expires on Cleanup Discon Open Session-Timeout expires on Cleanup Discon
home server home server
Open STR Received Send STA Idle Open STR Received Send STA Idle
Discon ASA Received Cleanup Idle Not ASA Received None No Change.
Open
Discon ASR Received None Discon Discon ASR Received None Discon
Discon STR Received Send STA Idle Discon STR Received Send STA Idle
Discon STA Received Discon. Idle Discon STA Received Discon. Idle
user/device user/device
The following state machine is used when state is not maintained on The following state machine is used when state is not maintained on
the server: the server:
skipping to change at page 86, line 7 skipping to change at page 91, line 7
state machine MUST be supported. state machine MUST be supported.
When a session is moved to the Idle state, any resources that were When a session is moved to the Idle state, any resources that were
allocated for the particular session must be released. Any event not allocated for the particular session must be released. Any event not
listed in the state machines MUST be considered as an error listed in the state machines MUST be considered as an error
condition, and an answer, if applicable, MUST be returned to the condition, and an answer, if applicable, MUST be returned to the
originator of the message. originator of the message.
State Event Action New State State Event Action New State
------------------------------------------------------------- -------------------------------------------------------------
Idle Client or device requests send Pending Idle Client or device requests send PendingS
access accounting access accounting
start req. start req.
Idle Accounting start request send Open Idle Accounting start request send Open
received, and successfully accounting received, and successfully accounting
processed. start processed. start
answer answer
Pending Successful accounting grant Open Idle Client or device requests send PendingE
start answer received access a one-time service accounting
event req
Idle Accounting event request send Idle
received, and successfully accounting
processed. event
answer
Idle Records in storage Send PendingB
record
Open Receive Interim Record send Open Open Receive Interim Record send Open
accounting accounting
answer answer
Open User service terminated send Discon Open User service terminated send PendingL
accounting accounting
stop req. stop req.
Open Accounting stop request send Idle Open Accounting stop request send Idle
received, and successfully accounting received, and successfully accounting
processed stop answer processed stop answer
Discon Successful accounting discon. Idle PendingL Successful accounting Idle
stop answer received user/device stop answer received
PendingL Failure to send and buffer Store Idle
space available Stop
Record
PendingL Failure to send and no buffer Idle
space available
PendingE Successful accounting Idle
event answer received
PendingE Failure to send and buffer Store Idle
space available Event
Record
PendingE Failure to send and no buffer Idle
space available
PendingS Successful accounting Open
start answer received
PendingS Failure to send and buffer Store Open
space available and realtime Start
not equal to DELIVER_AND_GRANT Record
PendingS Failure to send and no buffer Open
space available and realtime
equal to GRANT_AND_LOSE
PendingS Failure to send and no buffer Disconnect Idle
space available and realtime user/dev
not equal to
GRANT_AND_LOSE
PendingI Failure to send and (buffer Store Open
space available or old record Interim
can be overwritten) and Record
realtime not equal to
DELIVER_AND_GRANT
PendingI Failure to send and no buffer Open
space available and realtime
equal to GRANT_AND_LOSE
PendingI Failure to send and no buffer Disconnect Idle
space available and realtime user/dev
not equal to GRANT_AND_LOSE
PendingB Successful accounting answer Delete Idle
received record
PendingB Failure to send Idle
8.3 Server-Initiated Re-Auth 8.3 Server-Initiated Re-Auth
A Diameter server may initiate a re-authentication and/or re- A Diameter server may initiate a re-authentication and/or re-
authorization service for a particular session by issuing a Re-Auth- authorization service for a particular session by issuing a Re-Auth-
Request (RAR). Request (RAR).
For example, for pre-paid services, the Diameter server that For example, for pre-paid services, the Diameter server that
originally authorized a session may need some confirmation that the originally authorized a session may need some confirmation that the
user is still using the services. user is still using the services.
An access device that receives a RAR message with Session-Id equal to 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, a currently active session MUST initiate a re-auth towards the user,
if the service supports this particular feature. Each Diameter if the service supports this particular feature. Each Diameter
application MUST state whether service-initiated re-auth is application MUST state whether service-initiated re-auth is
supported, since some applications do not allow for access devices to supported, since some applications do not allow access devices to
prompt the user for re-auth. prompt the user for re-auth.
8.3.1 Re-Auth-Request 8.3.1 Re-Auth-Request
The Re-Auth-Request (RAR), indicated by the Command-Code set to 258 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 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 access device that is providing session service, to request that the
user be re-authenticated and/or re-authorized. user be re-authenticated and/or re-authorized.
Message Format Message Format
<RAR> ::= < Diameter Header: 258, REQ, PXY > <RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Destination-Host } { Destination-Host }
{ User-Name } { Auth-Application-Id }
{ Re-Auth-Request-Type } { Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ AVP ] * [ AVP ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
8.3.2 Re-Auth-Answer 8.3.2 Re-Auth-Answer
The Re-Auth-Answer (RAA), indicated by the Command-Code set to 258 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. 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 Result-Code AVP MUST be present, and indicates the disposition of
the request. the request.
A successful RAA message MUST be followed by an application-specific A successful RAA message MUST be followed by an application-specific
authentication and/or authorization message. authentication and/or authorization message.
Message Format Message Format
<RAR> ::= < Diameter Header: 258, PXY > <RAA> ::= < Diameter Header: 258, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ User-Name } [ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
* [ Failed-AVP ] * [ Failed-AVP ]
* [ Redirected-Host ] * [ Redirected-Host ]
[ Redirected-Host-Usage ] [ Redirected-Host-Usage ]
[ Redirected-Host-Cache-Time ] [ Redirected-Host-Cache-Time ]
* [ AVP ] * [ AVP ]
* [ Proxy-Info ] * [ Proxy-Info ]
skipping to change at page 88, line 31 skipping to change at page 94, line 31
It is necessary for a Diameter server that authorized a session, for It is necessary for a Diameter server that authorized a session, for
which it is maintaining state, to be notified when that session is no which it is maintaining state, to be notified when that session is no
longer active, both for tracking purposes as well as to allow longer active, both for tracking purposes as well as to allow
stateful agents to release any resources that they may have provided stateful agents to release any resources that they may have provided
for the user's session. For sessions whose state is not being for the user's session. For sessions whose state is not being
maintained, this section is not used. maintained, this section is not used.
When a user session that required Diameter authorization terminates, When a user session that required Diameter authorization terminates,
the access device that provided the service MUST issue a Session- the access device that provided the service MUST issue a Session-
Termination- Request (STR) message to the Diameter server that Termination-Request (STR) message to the Diameter server that
authorized the service, to notify it that the session is no longer 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 active. An STR MUST be issued when a user session terminates for any
reason, including user logoff, expiration of Session-Timeout, reason, including user logoff, expiration of Session-Timeout,
administrative action, termination upon receipt of an Abort-Session- administrative action, termination upon receipt of an Abort-Session-
Request (see below), orderly shutdown of the access device, etc. Request (see below), orderly shutdown of the access device, etc.
The access device also MUST issue an STR for a session that was The access device also MUST issue an STR for a session that was
authorized but never actually started. This could occur, for example, authorized but never actually started. This could occur, for example,
due to a sudden resource shortage in the access device, or because due to a sudden resource shortage in the access device, or because
the access device is unwilling to provide the type of service the access device is unwilling to provide the type of service
skipping to change at page 89, line 34 skipping to change at page 95, line 34
device to inform the Diameter Server that an authenticated and/or device to inform the Diameter Server that an authenticated and/or
authorized session is being terminated. authorized session is being terminated.
Message Format Message Format
<STR> ::= < Diameter Header: 275, REQ, PXY > <STR> ::= < Diameter Header: 275, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Auth-Application-Id }
{ Termination-Cause } { Termination-Cause }
[ User-Name ] [ User-Name ]
[ Destination-Host ] [ Destination-Host ]
* [ Class ] * [ Class ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ AVP ] * [ AVP ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
8.4.2 Session-Termination-Answer 8.4.2 Session-Termination-Answer
The Session-Termination-Answer (STA), indicated by the Command- Code The Session-Termination-Answer (STA), indicated by the Command-Code
set to 275 and the message flags' 'R' bit clear, is sent by the set to 275 and the message flags' 'R' bit clear, is sent by the
Diameter Server to acknowledge the notification that the session has Diameter Server to acknowledge the notification that the session has
been terminated. The Result-Code AVP MUST be present, and MAY contain been terminated. The Result-Code AVP MUST be present, and MAY contain
an indication that an error occurred while servicing the STR. an indication that an error occurred while servicing the STR.
Upon sending or receipt of the STA, the Diameter Server MUST release Upon sending or receipt of the STA, the Diameter Server MUST release
all resources for the session indicated by the Session-Id AVP. Any all resources for the session indicated by the Session-Id AVP. Any
intermediate server in the Proxy-Chain MAY also release any intermediate server in the Proxy-Chain MAY also release any
resources, if necessary. resources, if necessary.
Message Format Message Format
<STA> ::= < Diameter Header: 275, PXY > <STA> ::= < Diameter Header: 275, PXY >
< Session-Id > < Session-Id >
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
skipping to change at page 90, line 38 skipping to change at page 96, line 39
8.5 Aborting a Session 8.5 Aborting a Session
A Diameter server may request that the access device stop providing A Diameter server may request that the access device stop providing
service for a particular session by issuing an Abort-Session-Request service for a particular session by issuing an Abort-Session-Request
(ASR). (ASR).
For example, the Diameter server that originally authorized the For example, the Diameter server that originally authorized the
session may be required to cause that session to be stopped for session may be required to cause that session to be stopped for
credit or other reasons that were not anticipated when the session credit or other reasons that were not anticipated when the session
was first authorized. Or, an operator may maintain a management was first authorized. On the other hand, an operator may maintain a
server for the purpose of issuing ASRs to administratively remove management server for the purpose of issuing ASRs to administratively
users from the network. remove users from the network.
An access device that receives an ASR with Session-ID equal to a An access device that receives an ASR with Session-ID equal to a
currently active session MAY stop the session. Whether the access currently active session MAY stop the session. Whether the access
device stops the session or not is implementation- and/or device stops the session or not is implementation- and/or
configuration- dependent. For example, an access device may honor configuration-dependent. For example, an access device may honor ASRs
ASRs from certain agents only. In any case, the access device MUST from certain agents only. In any case, the access device MUST respond
respond with an Abort-Session-Answer, including a Result-Code AVP to with an Abort-Session-Answer, including a Result-Code AVP to indicate
indicate what action it took. what action it took.
Note that if the access device does stop the session upon receipt of 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 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 not be the agent issuing the ASR) just as it would if the session
were terminated for any other reason. were terminated for any other reason.
8.5.1 Abort-Session-Request 8.5.1 Abort-Session-Request
The Abort-Session-Request (ASR), indicated by the Command-Code set to 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 274 and the message flags' 'R' bit set, may be sent by any server to
skipping to change at page 91, line 22 skipping to change at page 97, line 25
the session identified by the Session-Id be stopped. the session identified by the Session-Id be stopped.
Message Format Message Format
<ASR> ::= < Diameter Header: 274, REQ, PXY > <ASR> ::= < Diameter Header: 274, REQ, PXY >
< Session-Id > < Session-Id >
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Destination-Host } { Destination-Host }
{ Auth-Application-Id }
[ User-Name ] [ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ AVP ] * [ AVP ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
8.5.2 Abort-Session-Answer 8.5.2 Abort-Session-Answer
The Abort-Session-Answer (ASA), indicated by the Command-Code set to 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 274 and the message flags' 'R' bit clear, is sent in response to the
skipping to change at page 92, line 38 skipping to change at page 98, line 38
whether the device has lost its sessions since the last connection. whether the device has lost its sessions since the last connection.
By including Origin-State-Id in request messages, an access device By including Origin-State-Id in request messages, an access device
also allows a server with which it communicates via proxy to make also allows a server with which it communicates via proxy to make
such a determination. However, a server that is not directly such a determination. However, a server that is not directly
connected with the access device will not discover that the access connected with the access device will not discover that the access
device has been restarted unless and until it receives a new request device has been restarted unless and until it receives a new request
from the access device. Thus, use of this mechanism across proxies is from the access device. Thus, use of this mechanism across proxies is
opportunistic rather than reliable, but useful nonetheless. opportunistic rather than reliable, but useful nonetheless.
When a Diameter server receives a Origin-State-Id that is greater When a Diameter server receives an Origin-State-Id that is greater
than the Origin-State-Id previously received from the same issuer, it than the Origin-State-Id previously received from the same issuer, it
may assume that the issuer has lost state since the previous message may assume that the issuer has lost state since the previous message
and that all sessions that were active under the lower Origin-State- and that all sessions that were active under the lower Origin-State-
Id have been terminated. The Diameter server MAY clean up all session Id have been terminated. The Diameter server MAY clean up all session
state associated with such lost sessions, and MAY also issues STRs state associated with such lost sessions, and MAY also issues STRs
for all such lost sessions that were authorized on upstream servers, for all such lost sessions that were authorized on upstream servers,
to allow session state to be cleaned up globally. to allow session state to be cleaned up globally.
8.7 Auth-Request-Type AVP 8.7 Auth-Request-Type AVP
skipping to change at page 94, line 7 skipping to change at page 100, line 7
The Session-Id MUST begin with the sender's identity encoded in the The Session-Id MUST begin with the sender's identity encoded in the
DiameterIdentity type (see section 4.4). The remainder of the DiameterIdentity type (see section 4.4). The remainder of the
Session-Id MAY be any sequence that the client can guarantee to be Session-Id MAY be any sequence that the client can guarantee to be
eternally unique; however, the following format is recommended, eternally unique; however, the following format is recommended,
(square brackets [] indicate an optional element): (square brackets [] indicate an optional element):
<DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>] <DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]
<high 32 bits> and <low 32 bits> are decimal representations of the <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 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 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 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. initialized to the time, and the low 32 bits MAY be initialized to
This will for practical purposes eliminate the possibility of zero. This will for practical purposes eliminate the possibility of
overlapping Session-Ids after a reboot, assuming the reboot process overlapping Session-Ids after a reboot, assuming the reboot process
takes longer than a second. Alternatively, an implementation MAY takes longer than a second. Alternatively, an implementation MAY keep
keep track of the increasing value in non-volatile memory. track of the increasing value in non-volatile memory.
<optional value> is implementation specific but may include a modem's <optional value> is implementation specific but may include a modem's
device Id, a layer 2 address, timestamp, etc. device Id, a layer 2 address, timestamp, etc.
Example, in which the standard port is used and there is no optional Example, in which there is no optional value:
value:
aaa://accesspoint7.acme.com;1876543210;523
or
accesspoint7.acme.com;1876543210;523 accesspoint7.acme.com;1876543210;523
Example, in which a non-standard port is used and there is an Example, in which there is an optional value:
optional value: accesspoint7.acme.com;1876543210;523;mobile@200.1.1.88
accesspoint7.acme.com:831;1876543210;523;mobile@200.1.1.88
The session Id is created by the Diameter device initiating the The Session-Id is created by the Diameter device initiating the
session, which in most cases is done by the client. Note that a session, which in most cases is done by the client. Note that a
Session-Id MAY be used for both the authorization and accounting Session-Id MAY be used for both the authorization and accounting
commands of a given application. commands of a given application.
8.9 Authorization-Lifetime AVP 8.9 Authorization-Lifetime AVP
The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32
and contains the maximum number of seconds of service to be provided 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- to the user before the user is to be re-authenticated and/or re-
authorized. Great care should be taken when the Authorization- authorized. Great care should be taken when the Authorization-
Lifetime value is determined, since a low, non-zero, value could Lifetime value is determined, since a low, non-zero, value could
create significant Diameter traffic, which could congest both the create significant Diameter traffic, which could congest both the
network and the agents. network and the agents.
A value of zero (0) means that immediate re-auth is necessary by the A value of zero (0) means that immediate re-auth is necessary by the
access device. This is typically used in cases where multiple access device. This is typically used in cases where multiple
authentication methods are used, and a successful auth response with authentication methods are used, and a successful auth response with
this AVP set to one is used to signal that the next authentication this AVP set to zero is used to signal that the next authentication
method is to be immediately initiated. The absence of this AVP, or a method is to be immediately initiated. The absence of this AVP, or a
value of all ones (meaning all bits in the 32 bit field are set to value of all ones (meaning all bits in the 32 bit field are set to
one) means no re-auth is expected. one) means no re-auth is expected.
If both this AVP and the Session-Timeout AVP are present in a 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 message, the value of the latter MUST NOT be smaller than the
Authorization-Lifetime AVP. Authorization-Lifetime AVP.
An Authorization-Lifetime AVP MAY be present in a re-authorization An Authorization-Lifetime AVP MAY be present in re-authorization
messages, and contains the number of seconds the user is authorized messages, and contains the number of seconds the user is authorized
to receive service from the time the re-auth answer message is to receive service from the time the re-auth answer message is
received by the access device. received by the access device.
This AVP MAY be provided by the client as a hint of the maximum This AVP MAY be provided by the client as a hint of the maximum
lifetime that it is willing to accept. However, the server MAY return lifetime that it is willing to accept. However, the server MAY return
a value that is equal to, or smaller, than the one provided by the a value that is equal to, or smaller, than the one provided by the
client. client.
8.10 Auth-Grace-Period AVP 8.10 Auth-Grace-Period AVP
The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and The Auth-Grace-Period AVP (AVP Code 276) is of type Unsigned32 and
contains the number of seconds the Diameter server will wait contains the number of seconds the Diameter server will wait
following the expiration of the Authorization-Lifetime AVP before following the expiration of the Authorization-Lifetime AVP before
cleaning up resources for the session. cleaning up resources for the session.
This AVP MAY be provided by the client as a hint of the maximum
lifetime that it is willing to accept. However, the server MAY return
a value that is equal to, or smaller, than the one provided by the
client.
8.11 Auth-Session-State AVP 8.11 Auth-Session-State AVP
The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and The Auth-Session-State AVP (AVP Code 277) is of type Enumerated and
specifies whether state is maintained for a particular session. The specifies whether state is maintained for a particular session. The
client MAY include this AVP in requests as a hint to the server, but client MAY include this AVP in requests as a hint to the server, but
the value in the server's answer message is binding. The following the value in the server's answer message is binding. The following
values are supported: values are supported:
STATE_MAINTAINED 0 STATE_MAINTAINED 0
This value is used to specify that session state is being This value is used to specify that session state is being
skipping to change at page 96, line 4 skipping to change at page 101, line 40
maintained, and the access device MUST issue a session maintained, and the access device MUST issue a session
termination message when service to the user is terminated. termination message when service to the user is terminated.
This is the default value. This is the default value.
NO_STATE_MAINTAINED 1 NO_STATE_MAINTAINED 1
This value is used to specify that no session termination This value is used to specify that no session termination
messages will be sent by the access device upon expiration of messages will be sent by the access device upon expiration of
the Authorization-Lifetime. the Authorization-Lifetime.
8.12 Re-Auth-Request-Type AVP 8.12 Re-Auth-Request-Type AVP
The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and 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 is included in application-specific auth answers to inform the client
of the action expected upon expiration of the Authorization-Lifetime. of the action expected upon expiration of the Authorization-Lifetime.
The following values are defined: The following values are defined:
AUTHORIZE_ONLY 0 AUTHORIZE_ONLY 0
An authorization only re-auth is expected upon expiration of An authorization only re-auth is expected upon expiration of
the Authorization-Lifetime. This is the default value if the the Authorization-Lifetime. This is the default value if the
AVP is not present in answer messages that include the AVP is not present in answer messages that include the
Authorization-Lifetime. Authorization-Lifetime.
AUTHORIZE_AUTHENTICATE 1 AUTHORIZE_AUTHENTICATE 1
An authentication and authorization re-auth is expected upon An authentication and authorization re-auth is expected upon
expiration of the Authorization-Lifetime. expiration of the Authorization-Lifetime.
8.13 Session-Timeout AVP 8.13 Session-Timeout AVP
The Session-Timeout AVP (AVP Code 27) [1] is of type Unsigned32 and The Session-Timeout AVP (AVP Code 27) [RADIUS] is of type Unsigned32
contains the maximum number of seconds of service to be provided to and contains the maximum number of seconds of service to be provided
the user before termination of the session. When both the Session- to the user before termination of the session. When both the Session-
Timeout and the Authorization-Lifetime AVPs are present in an answer 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 message, the former MUST be equal to or greater than the value of the
latter. latter.
A session that terminates on an access device due to the expiration A session that terminates on an access device due to the expiration
of the Session-Timeout MUST cause an STR to be issued, unless both of the Session-Timeout MUST cause an STR to be issued, unless both
the access device and the home server had previously agreed that no the access device and the home server had previously agreed that no
session termination messages would be sent (see section 8.9). session termination messages would be sent (see section 8.9).
A Session-Timeout AVP MAY be present in a re-authorization messages, A Session-Timeout AVP MAY be present in a re-authorization message,
and contains the number of seconds from the beginning of the re-auth. 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 A value of zero, or the absence of this AVP, means that this session
has an unlimited number of seconds before termination. has an unlimited number of seconds before termination.
This AVP MAY be provided by the client as a hint of the maximum This AVP MAY be provided by the client as a hint of the maximum
timeout that it is willing to accept. However, the server MAY return timeout that it is willing to accept. However, the server MAY return
a value that is equal to, or smaller, than the one provided by the a value that is equal to, or smaller, than the one provided by the
client. client.
8.14 User-Name AVP 8.14 User-Name AVP
The User-Name AVP (AVP Code 1) [1] is of type UTF8String, which The User-Name AVP (AVP Code 1) [RADIUS] is of type UTF8String, which
contains the User-Name, in a format consistent with the NAI contains the User-Name, in a format consistent with the NAI
specification [8]. specification [NAI].
8.15 Termination-Cause AVP 8.15 Termination-Cause AVP
The Termination-Cause AVP (AVP Code 295) is of type Enumerated, and 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 is used to indicate the reason why a session was terminated on the
access device. The following values are defined: access device. The following values are defined:
DIAMETER_LOGOUT 1 DIAMETER_LOGOUT 1
The user initiated a disconnect The user initiated a disconnect
skipping to change at page 98, line 12 skipping to change at page 104, line 5
this AVP each time its state is reset. A Diameter entity MAY set 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 Origin-State-Id to the time of startup, or it MAY use an incrementing
counter retained in non-volatile memory across restarts. counter retained in non-volatile memory across restarts.
The Origin-State-Id, if present, MUST reflect the state of the entity 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 indicated by Origin-Host. If a proxy modifies Origin-Host, it MUST
either remove Origin-State-Id or modify it appropriately as well. either remove Origin-State-Id or modify it appropriately as well.
Typically, Origin-State-Id is used by an access device that always Typically, Origin-State-Id is used by an access device that always
starts up with no active sessions; that is, any session active prior 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 to restart will have been lost. By including Origin-State-Id in a
a message, it allows other Diameter entities to infer that sessions message, it allows other Diameter entities to infer that sessions
associated with a lower Origin-State-Id are no longer active. If an 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 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 either not include Origin-State-Id in any message, or set its value
to 0. to 0.
8.17 Session-Binding AVP 8.17 Session-Binding AVP
The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY The Session-Binding AVP (AVP Code 270) is of type Unsigned32, and MAY
be present in application-specific authorization answer messages. If be present in application-specific authorization answer messages. If
present, this AVP MAY inform the Diameter client that all future present, this AVP MAY inform the Diameter client that all future
skipping to change at page 100, line 19 skipping to change at page 106, line 12
found in any previous authorization answer message. Diameter server found in any previous authorization answer message. Diameter server
implementations SHOULD NOT return Class AVPs that require more than implementations SHOULD NOT return Class AVPs that require more than
4096 bytes of storage on the Diameter client. A Diameter client that 4096 bytes of storage on the Diameter client. A Diameter client that
receives Class AVPs whose size exceeds local available storage MUST receives Class AVPs whose size exceeds local available storage MUST
terminate the session. terminate the session.
9.0 Accounting 9.0 Accounting
This accounting protocol is based on a server directed model with This accounting protocol is based on a server directed model with
capabilities for real-time delivery of accounting information. capabilities for real-time delivery of accounting information.
Several fault resilience methods [40] have been built in to the Several fault resilience methods [ACCMGMT] have been built in to the
protocol in order minimize loss of accounting data in various fault protocol in order minimize loss of accounting data in various fault
situations and under different assumptions about the capabilities of situations and under different assumptions about the capabilities of
the used devices. the used devices.
9.1 Server Directed Model 9.1 Server Directed Model
The server directed model means that the device generating the The server directed model means that the device generating the
accounting data gets information from either the authorization server accounting data gets information from either the authorization server
(if contacted) or the accounting server regarding the way accounting (if contacted) or the accounting server regarding the way accounting
data shall be forwarded. This information includes accounting record data shall be forwarded. This information includes accounting record
timeliness requirements. timeliness requirements.
As discussed in [40], real-time transfer of accounting records is a As discussed in [ACCMGMT], real-time transfer of accounting records
requirement, such as the need to perform credit limit checks and is a requirement, such as the need to perform credit limit checks and
fraud detection. Note that batch accounting is not a requirement, and fraud detection. Note that batch accounting is not a requirement, and
is therefore not supported by Diameter. Should Batched Accounting be is therefore not supported by Diameter. Should Batched Accounting be
required in the future, a new Diameter application will need to be required in the future, a new Diameter application will need to be
created, or it could be handled using another protocol. created, or it could be handled using another protocol.
The authorization server (chain) directs the selection of proper The authorization server (chain) directs the selection of proper
transfer strategy, based on its knowledge of the user and transfer strategy, based on its knowledge of the user and
relationships of roaming partnerships. The server (or agents) uses relationships of roaming partnerships. The server (or agents) uses
the Accounting-Interim-Interval AVP to control the operation of the the Accounting-Interim-Interval AVP to control the operation of the
Diameter peer operating as a client. The Accounting-Interim-Interval Diameter peer operating as a client. The Accounting-Interim-Interval
skipping to change at page 101, line 9 skipping to change at page 106, line 48
produce accounting records continuously even during a session. produce accounting records continuously even during a session.
The Diameter accounting server MAY override the interim interval by The Diameter accounting server MAY override the interim interval by
including an Accounting-Interim-Interval AVP in the Accounting-Answer including an Accounting-Interim-Interval AVP in the Accounting-Answer
message. When the AVP is present, the latest value received SHOULD be message. When the AVP is present, the latest value received SHOULD be
used in the generation of interim accounting messages. used in the generation of interim accounting messages.
9.2 Protocol Messages 9.2 Protocol Messages
A Diameter node that receives a successful authentication and/or A Diameter node that receives a successful authentication and/or
authorization messages from the Home AAA Server, MUST collect authorization messages from the Home AAA server MUST collect
accounting information for the session. The Accounting-Request accounting information for the session. The Accounting-Request
message is used to transmit the accounting information to the Home message is used to transmit the accounting information to the Home
AAA server, which MUST reply with the Accounting-Answer message to AAA server, which MUST reply with the Accounting-Answer message to
confirm reception. The Accounting-Answer message includes the confirm reception. The Accounting-Answer message includes the Result-
Result-Code AVP, which MAY indicate that an error was present in the Code AVP, which MAY indicate that an error was present in the
accounting message. A rejected Accounting-Request message SHOULD accounting message. A rejected Accounting-Request message SHOULD
cause the user's session to be terminated. cause the user's session to be terminated.
Each Diameter Accounting protocol message MAY be compressed using Each Diameter Accounting protocol message MAY be compressed using
IPComp [41] in order to reduce the used network bandwidth, which MAY IPComp [IPComp] in order to reduce the used network bandwidth, which
use IKE [15] to negotiate the compression parameters. MAY use IKE [IKE] to negotiate the compression parameters.
9.3 Application document requirements 9.3 Application document requirements
Each Diameter application (e.g. NASREQ, MobileIP), MUST define their Each Diameter application (e.g. NASREQ, MobileIP), MUST define their
Service-Specific AVPs that MUST be present in the Accounting-Request Service-Specific AVPs that MUST be present in the Accounting-Request
message in a section entitled "Accounting AVPs". The application MUST message in a section entitled "Accounting AVPs". The application MUST
assume that the AVPs described in this document will be present in assume that the AVPs described in this document will be present in
all Accounting messages, so only their respective service-specific all Accounting messages, so only their respective service-specific
AVPs need to be defined in this section. AVPs need to be defined in this section.
skipping to change at page 101, line 42 skipping to change at page 107, line 36
Diameter Base protocol mechanisms are used to overcome small message Diameter Base protocol mechanisms are used to overcome small message
loss and network faults of temporary nature. loss and network faults of temporary nature.
Diameter peers acting as clients MUST implement the use of failover Diameter peers acting as clients MUST implement the use of failover
to guard against server failures and certain network failures. to guard against server failures and certain network failures.
Diameter peers acting as agents or related off-line processing Diameter peers acting as agents or related off-line processing
systems MUST detect duplicate accounting records caused by the systems MUST detect duplicate accounting records caused by the
sending of same record to several servers and duplication of messages sending of same record to several servers and duplication of messages
in transit. This detection MUST be based on the inspection of the in transit. This detection MUST be based on the inspection of the
Session-Id and Accounting-Record-Number AVP pairs. Session-Id and Accounting-Record-Number AVP pairs. Appendix C
discusses duplicate detection need and implementation issues.
Diameter clients MAY have non-volatile memory for the safe storage of Diameter clients MAY have non-volatile memory for the safe storage of
accounting records over reboots or extended network failures, network accounting records over reboots or extended network failures, network
partitions, and server failures. If such memory is available the partitions, and server failures. If such memory is available, the
client SHOULD store new accounting records there as soon as the client SHOULD store new accounting records there as soon as the
records are created and until a positive acknowledgement of their records are created and until a positive acknowledgement of their
reception from the Diameter Server has been received. Upon a reboot, reception from the Diameter Server has been received. Upon a reboot,
the client MUST starting sending the records in the non-volatile the client MUST starting sending the records in the non-volatile
memory to the accounting server with appropriate modifications in memory to the accounting server with appropriate modifications in
termination cause, session length, and other relevant information in termination cause, session length, and other relevant information in
the records. the records.
A further application of this protocol may include AVPs to control A further application of this protocol may include AVPs to control
how many accounting records may at most be stored in the Diameter how many accounting records may at most be stored in the Diameter
skipping to change at page 102, line 24 skipping to change at page 108, line 19
The client SHOULD NOT remove the accounting data from any of its The client SHOULD NOT remove the accounting data from any of its
memory areas before the correct Accounting-Answer has been received. memory areas before the correct Accounting-Answer has been received.
The client MAY remove oldest, undelivered or yet unacknowledged The client MAY remove oldest, undelivered or yet unacknowledged
accounting data if it runs out of resources such as memory. It is an accounting data if it runs out of resources such as memory. It is an
implementation dependent matter for the client to accept new sessions implementation dependent matter for the client to accept new sessions
under this condition. under this condition.
9.5 Accounting Records 9.5 Accounting Records
In all accounting records the Session-Id and User-Name AVPs MUST be In all accounting records, the Session-Id AVP MUST be present; the
present. If strong authentication across agents is required, as User-Name AVP MUST be present if it is available to the Diameter
described in [11], the CMS-Signed-Data AVP may be used to client. If strong authentication across agents is required, as
described in [CMS], the CMS-Signed-Data AVP may be used to
authenticate the Accounting Data and Service Specific AVPs. It is not authenticate the Accounting Data and Service Specific AVPs. It is not
typically necessary that the CMS-Signed-Data AVP cover any additional typically necessary that the CMS-Signed-Data AVP cover any additional
AVPs, but it is permitted as long as the AVPs protected are defined AVPs, but it is permitted as long as the AVPs protected are defined
to have their 'P' bit set. to have their 'P' bit set.
Different types of accounting records are sent depending on the Different types of accounting records are sent depending on the
actual type of accounted service and the authorization server's actual type of accounted service and the authorization server's
directions for interim accounting. If the accounted service is a one- directions for interim accounting. If the accounted service is a one-
time event, meaning that the start and stop of the event are time event, meaning that the start and stop of the event are
simultaneous, then the Accounting-Record-Type AVP MUST be present and simultaneous, then the Accounting-Record-Type AVP MUST be present and
set to the value EVENT_RECORD. set to the value EVENT_RECORD.
If the accounted service is of a measurable length, then the AVP MUST If the accounted service is of a measurable length, then the AVP MUST
use the values START_RECORD, STOP_RECORD, and possibly, use the values START_RECORD, STOP_RECORD, and possibly,
INTERIM_RECORD. If the authorization server has directed interim INTERIM_RECORD. If the authorization server has directed interim
accounting to be enabled for the session, but no interim interval was accounting to be enabled for the session, but no interim interval was
specified, two accounting records MUST be generated for each service specified, two accounting records MUST be generated for each service
of type session. When the initial Accounting-Request is sent for a of type session. When the initial Accounting-Request for a given
given session is sent, the Accounting-Record-Type AVP MUST be set to session is sent, the Accounting-Record-Type AVP MUST be set to the
the value START_RECORD. When the last Accounting-Request is sent, the value START_RECORD. When the last Accounting-Request is sent, the
value MUST be STOP_RECORD. value MUST be STOP_RECORD.
If a specified interim interval exists, the Diameter client MUST If a specified interim interval exists, the Diameter client MUST
produce additional records between the START_RECORD and STOP_RECORD, produce additional records between the START_RECORD and STOP_RECORD,
marked INTERIM_RECORD. The production of these records is directed marked INTERIM_RECORD. The production of these records is directed by
both by Accounting-Interim-Interval as well as any re-authentication both Accounting-Interim-Interval as well as any re-authentication or
or re-authorization of the session. The Diameter client MUST re-authorization of the session. The Diameter client MUST overwrite
overwrite any previous interim accounting records that are locally any previous interim accounting records that are locally stored for
stored for delivery, if a new record is being generated for the same delivery, if a new record is being generated for the same session.
session. This ensures that only one pending interim record can exist
on an access device for any given session. This ensures that only one pending interim record can exist on an
access device for any given session.
A particular value of Accounting-Sub-Session-Id MUST appear only in A particular value of Accounting-Sub-Session-Id MUST appear only in
one sequence of accounting records from a DIAMETER client, except for one sequence of accounting records from a DIAMETER client, except for
the purposes of retransmission. The one sequence that is sent MUST the purposes of retransmission. The one sequence that is sent MUST
be either one record with Accounting-Record-Type AVP set to the value be either one record with Accounting-Record-Type AVP set to the value
EVENT_RECORD, or several records starting with one having 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 START_RECORD, followed by zero or more INTERIM_RECORD and a single
STOP_RECORD. A particular Diameter application specification MUST STOP_RECORD. A particular Diameter application specification MUST
define the type of sequences that MUST be used. define the type of sequences that MUST be used.
9.6 Correlation of Accounting Records 9.6 Correlation of Accounting Records
The Diameter protocol's Session-Id AVP, which is globally unique (see The Diameter protocol's Session-Id AVP, which is globally unique (see
section 8.8), is used during the authorization phase to identify a section 8.8), is used during the authorization phase to identify a
particular session. Services that do not require any authorization particular session. Services that do not require any authorization
still use the Session-Id AVP to identify sessions. still use the Session-Id AVP to identify sessions.
skipping to change at page 103, line 41 skipping to change at page 109, line 37
AVP. In these cases, correlation is performed using the Session-Id. AVP. In these cases, correlation is performed using the Session-Id.
It is important to note that receiving a STOP_RECORD with no It is important to note that receiving a STOP_RECORD with no
Accounting-Sub-Session-Id AVP when sub-sessions were originally used Accounting-Sub-Session-Id AVP when sub-sessions were originally used
in the START_RECORD messages implies that all sub-sessions are in the START_RECORD messages implies that all sub-sessions are
terminated. terminated.
Furthermore, there are certain applications where a user receives Furthermore, there are certain applications where a user receives
service from different access devices (e.g. Mobile IP), each with service from different access devices (e.g. Mobile IP), each with
their own unique Session-Id. In such cases, the Accounting-Multi- their own unique Session-Id. In such cases, the Accounting-Multi-
Session-Id AVP is used for correlation. During authorization, a Session-Id AVP is used for correlation. During authorization, a
server that determines that a request is for an existing session, server that determines that a request is for an existing session
SHOULD include the Accounting-Multi-Session-Id AVP, which the access SHOULD include the Accounting-Multi-Session-Id AVP, which the access
device MUST include in all subsequent accounting messages. device MUST include in all subsequent accounting messages.
The Accounting-Multi-Session-Id AVP MAY include the value of the The Accounting-Multi-Session-Id AVP MAY include the value of the
original Session-Id. It's contents are implementation specific, but original Session-Id. It's contents are implementation specific, but
MUST be globally unique across other Accounting-Multi-Session-Id, and MUST be globally unique across other Accounting-Multi-Session-Id, and
MUST NOT change during the life of a session. MUST NOT change during the life of a session.
A Diameter application document MUST define the exact concept of a A Diameter application document MUST define the exact concept of a
session that is being accounted, and MAY define the 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 multi-session. For instance, the NASREQ DIAMETER application treats a
single PPP connection to a Network Access Server as one session, and single PPP connection to a Network Access Server as one session, and
a set of Multilink PPP sessions as one multi-session. a set of Multilink PPP sessions as one multi-session.
9.7 Accounting Command-Codes 9.7 Accounting Command-Codes
This section defines new Command-Code values that MUST be supported This section defines new Command-Code values that MUST be supported
by all Diameter implementations that provide Accounting services. by all Diameter implementations that provide Accounting services.
9.7.1 Accounting-Request 9.7.1 Accounting-Request
The Accounting-Request (ACR) command, indicated by the Command-Code The Accounting-Request (ACR) command, indicated by the Command-Code
field set to 271 and the Command Flags' 'R' bit set, is sent by a 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 Diameter node, acting as a client, in order to exchange accounting
information with a peer. information with a peer.
When the Accounting-Request is being submitted to a third party (e.g. When the Accounting-Request is being submitted to a third party (e.g.
settlement service), and includes the CMS-Signed-Data AVP [11], the settlement service), and includes the CMS-Signed-Data AVP [CMS], the
CMS-Signed-Data AVP MUST be signed by both the local and home CMS-Signed-Data AVP MUST be signed by both the local and home
Diameter server using the countersignature procedures described in Diameter server using the countersignature procedures described in
[11]. [CMS].
The AVP listed below SHOULD include service specific accounting AVPs, The AVP listed below SHOULD include service specific accounting AVPs,
as described in section 9.3. as described in section 9.3.
Message Format Message Format
<ACR> ::= < Diameter Header: 271, REQ, PXY > <ACR> ::= < Diameter Header: 271, REQ, PXY >
< Session-Id > < Session-Id >
{ Acct-Application-Id } { Acct-Application-Id }
{ Origin-Host } { Origin-Host }
skipping to change at page 106, line 24 skipping to change at page 112, line 19
An Accounting Start, Interim, and Stop Records are used to An Accounting Start, Interim, and Stop Records are used to
indicate that a service of a measurable length has been given. indicate that a service of a measurable length has been given.
An Accounting Start Record is used to initiate an accounting An Accounting Start Record is used to initiate an accounting
session, and contains accounting information that is relevant session, and contains accounting information that is relevant
to the initiation of the session. to the initiation of the session.
INTERIM_RECORD 3 INTERIM_RECORD 3
An Interim Accounting Record contains cumulative accounting An Interim Accounting Record contains cumulative accounting
information for an existing accounting session. Interim information for an existing accounting session. Interim
Accounting Records SHOULD be sent every time a re- Accounting Records SHOULD be sent every time a re-
authentication or re-authorization occurs. Further, additional authentication or re-authorization occurs. Further, additional
interim record triggers MAY be defined by application-specific interim record triggers MAY be defined by application-specific
Diameter applications. The selection of whether to use Diameter applications. The selection of whether to use
INTERIM_RECORD records is directed by the Accounting-Interim- INTERIM_RECORD records is directed by the Accounting-Interim-
Interval AVP. Interval AVP.
STOP_RECORD 4 STOP_RECORD 4
An Accounting Stop Record is sent to terminate an accounting An Accounting Stop Record is sent to terminate an accounting
session and contains cumulative accounting information relevant session and contains cumulative accounting information relevant
to the existing session. to the existing session.
skipping to change at page 107, line 7 skipping to change at page 112, line 48
following accounting record production behavior is directed by the following accounting record production behavior is directed by the
inclusion of this AVP: inclusion of this AVP:
1. The omission of the Accounting-Interim-Interval AVP or its 1. The omission of the Accounting-Interim-Interval AVP or its
inclusion with Value field set to 0 means that EVENT_RECORD, inclusion with Value field set to 0 means that EVENT_RECORD,
START_RECORD, and STOP_RECORD are produced, as appropriate for START_RECORD, and STOP_RECORD are produced, as appropriate for
the service. the service.
2. The inclusion of the AVP with Value field set to a non-zero 2. The inclusion of the AVP with Value field set to a non-zero
value means that INTERIM_RECORD records MUST be produced value means that INTERIM_RECORD records MUST be produced
between the START_RECORD and STOP_RECORD records. The Value between the START_RECORD and STOP_RECORD records. The Value
field of this AVP is the nominal interval between these records field of this AVP is the nominal interval between these records
in seconds. The Diameter node that originates the accounting in seconds. The Diameter node that originates the accounting
information, known as the client, MUST produce the first information, known as the client, MUST produce the first
INTERIM_RECORD record roughly at the time when this nominal INTERIM_RECORD record roughly at the time when this nominal
interval has elapsed from the START_RECORD, the next one again interval has elapsed from the START_RECORD, the next one again
as the interval has elapsed once more, and so on until the as the interval has elapsed once more, and so on until the
session ends and a STOP_RECORD record is produced. session ends and a STOP_RECORD record is produced.
The client MUST ensure that the interim record production times The client MUST ensure that the interim record production times
are randomized so that large accounting message storms are not are randomized so that large accounting message storms are not
skipping to change at page 107, line 46 skipping to change at page 113, line 40
OctetString is only used when RADIUS/Diameter translation occurs. OctetString is only used when RADIUS/Diameter translation occurs.
This AVP contains the contents of the RADIUS Accounting-Session-Id This AVP contains the contents of the RADIUS Accounting-Session-Id
attribute. attribute.
9.8.5 Accounting-Multi-Session-Id AVP 9.8.5 Accounting-Multi-Session-Id AVP
The Accounting-Multi-Session-Id AVP (AVP Code 50) is of type The Accounting-Multi-Session-Id AVP (AVP Code 50) is of type
UTF8String, following the format specified in section 8.8. The UTF8String, following the format specified in section 8.8. The
Accounting-Multi-Session-Id AVP is used to link together multiple Accounting-Multi-Session-Id AVP is used to link together multiple
related accounting sessions, where each session would have a unique related accounting sessions, where each session would have a unique
Session-Id, but the same Accounting-Multi-Session-Id AVP. This AVP Session-Id, but the same Accounting-Multi-Session-Id AVP. This AVP
MAY be returned by the Diameter server in an authorization answer, MAY be returned by the Diameter server in an authorization answer,
and MUST be used in all accounting messages for the given session. and MUST be used in all accounting messages for the given session.
9.8.6 Accounting-Sub-Session-Id AVP 9.8.6 Accounting-Sub-Session-Id AVP
The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type The Accounting-Sub-Session-Id AVP (AVP Code 287) is of type
Unsigned64 and contains the accounting sub-session identifier. The Unsigned64 and contains the accounting sub-session identifier. The
combination of the Session-Id and this AVP MUST be unique per sub- combination of the Session-Id and this AVP MUST be unique per sub-
session, and the value of this AVP MUST be monotonically increased by session, and the value of this AVP MUST be monotonically increased by
one for all new sub-sessions. The absence of this AVP implies no sub- one for all new sub-sessions. The absence of this AVP implies no sub-
sessions are in use, with the exception of an Accounting-Request sessions are in use, with the exception of an Accounting-Request
whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD whose Accounting-Record-Type is set to STOP_RECORD. A STOP_RECORD
message with no Accounting-Sub-Session-Id AVP present will signal the message with no Accounting-Sub-Session-Id AVP present will signal the
termination of all sub-sessions for a given Session-Id. termination of all sub-sessions for a given Session-Id.
9.8.7 Accounting-Realtime-Required AVP
The Accounting-Realtime-Required AVP (AVP Code TBD) is of type
Enumerated and is sent from the Diameter home authorization server to
the Diameter client or in the Accounting-Answer from the accounting
server. The client uses information in this AVP to decide what to do
if the sending of accounting records to the accounting server has
been temporarily prevented due to, for instance, a network problem.
DELIVER_AND_GRANT 1
The AVP with Value field set to DELIVER_AND_GRANT means that
the service MUST only be granted as long as there is a
connection to an accounting server. Note that the set of
alternative accounting servers are treated as one server in
this sense. Having to move the accounting record stream to a
backup server is not a reason to discontinue the service to the
user.
GRANT_AND_STORE 2
The AVP with Value field set to GRANT_AND_STORE means that
service SHOULD be granted if there is a connection, or as long
as records can still be stored as described in section 9.4.
This is the default behaviour if the AVP isn't included in the
reply from the authorization server.
GRANT_AND_LOSE 3
The AVP with Value field set to GRANT_AND_LOSE means that
service SHOULD be granted even if the records can not be
delivered or stored.
10.0 AVP Occurrence Table 10.0 AVP Occurrence Table
The following tables presents the AVPs defined in this document, and The following tables presents the AVPs defined in this document, and
specifies in which Diameter messages they MAY, or MAY NOT be present. 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 Note that AVPs that can only be present within a Grouped AVP are not
represented in this table. represented in this table.
The table uses the following symbols: The table uses the following symbols:
0 The AVP MUST NOT be present in the message. 0 The AVP MUST NOT be present in the message.
0+ Zero or more instances of the AVP MAY be present in the 0+ Zero or more instances of the AVP MAY be present in the
message. message.
0-1 Zero or one instance of the AVP MAY be present in the 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 message. It is considered an error if there are more than
once instance of the AVP. once instance of the AVP.
1 One instance of the AVP MUST be present in the message. 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 1+ At least one instance of the AVP MUST be present in the
message. message.
10.1 Base Protocol Command AVP Table 10.1 Base Protocol Command AVP Table
The table in this section is limited to the non-accounting Command The table in this section is limited to the non-accounting Command
Codes Codes defined in this specification.
defined in this specification.
+-----------------------------------------------+ +-----------------------------------------------+
| Command-Code | | Command-Code |
|---+---+---+---+---+---+---+---+---+---+---+---+ |---+---+---+---+---+---+---+---+---+---+---+---+
Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA|
--------------------|---+---+---+---+---+---+---+---+---+---+---+---| --------------------|---+---+---+---+---+---+---+---+---+---+---+---|
Accounting-Interim- |0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
Interval | | | | | | | | | | | | |
Accounting-Realtime-|0 |0 |0 |0 |0 |0 |0-1|0 |0 |0 |0 |0 |
Required | | | | | | | | | | | | |
Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Acct-Application-Id |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 | Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Auth-Grace-Period |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 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-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 | 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 | Authorization- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Lifetime | | | | | | | | | | | | | Lifetime | | | | | | | | | | | | |
Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ | Class |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0+ |0+ |
Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 | Destination-Host |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |0-1|0 |
Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | Destination-Realm |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 |
Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Disconnect-Cause |0 |0 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1| Error-Message |0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|0 |0-1|
skipping to change at page 109, line 46 skipping to change at page 116, line 50
Result-Code |0 |1 |0 |1 |0 |1 |0 |1 |0 |0 |0 |1 | 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 | 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 | 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-Binding |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 | Session-Id |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 |
Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Session-Server- |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Failover | | | | | | | | | | | | | Failover | | | | | | | | | | | | |
Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Session-Timeout |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Supported-Vendor-Id |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | 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 | Termination-Cause |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |1 |0 |
User-Name |0 |0 |0 |0 |0 |0 |1 |1 |1 |1 |1 |1 | User-Name |0 |0 |0 |0 |0 |0 |0-1|0-1|1 |1 |1 |1 |
Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Vendor-Id |1 |1 |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Vendor-Specific- |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 |
Application-Id | | | | | | | | | | | | | Application-Id | | | | | | | | | | | | |
--------------------|---+---+---+---+---+---+---+---+---+---+---+---| --------------------|---+---+---+---+---+---+---+---+---+---+---+---|
10.2 Accounting AVP Table 10.2 Accounting AVP Table
The table in this section is used to represent which AVPs defined in The table in this section is used to represent which AVPs defined in
this document are to be present in the Accounting messages. this document are to be present in the Accounting messages.
+-----------+ +-----------+
skipping to change at page 110, line 21 skipping to change at page 117, line 23
| Code | | Code |
|-----+-----+ |-----+-----+
Attribute Name | ACR | ACA | Attribute Name | ACR | ACA |
------------------------------|-----+-----+ ------------------------------|-----+-----+
Accounting-Interim-Interval | 0-1 | 0-1 | Accounting-Interim-Interval | 0-1 | 0-1 |
Accounting-Multi-Session-Id | 0-1 | 0-1 | Accounting-Multi-Session-Id | 0-1 | 0-1 |
Accounting-Record-Number | 1 | 1 | Accounting-Record-Number | 1 | 1 |
Accounting-Record-Type | 1 | 1 | Accounting-Record-Type | 1 | 1 |
Accounting-RADIUS-Session-Id | 0-1 | 0-1 | Accounting-RADIUS-Session-Id | 0-1 | 0-1 |
Accounting-Sub-Session-Id | 0-1 | 0-1 | Accounting-Sub-Session-Id | 0-1 | 0-1 |
Accounting-Realtime-Required | 0 | 0-1 |
Acct-Application-Id | 1 | 1 | Acct-Application-Id | 1 | 1 |
Class | 0+ | 0+ | Class | 0+ | 0+ |
Destination-Host | 0-1 | 0 | Destination-Host | 0-1 | 0 |
Destination-Realm | 1 | 0 | Destination-Realm | 1 | 0 |
Error-Reporting-Host | 0 | 0+ | Error-Reporting-Host | 0 | 0+ |
Max-Time-Wait | 0+ | 0 |
Origin-Host | 1 | 1 | Origin-Host | 1 | 1 |
Origin-Realm | 1 | 1 | Origin-Realm | 1 | 1 |
Proxy-Info | 0+ | 0+ | Proxy-Info | 0+ | 0+ |
Route-Record | 0+ | 0+ | Route-Record | 0+ | 0+ |
Result-Code | 0 | 1 | Result-Code | 0 | 1 |
Session-Id | 1 | 1 | Session-Id | 1 | 1 |
User-Name | 1 | 1 | User-Name | 0+ | 0+ |
------------------------------|-----+-----+ ------------------------------|-----+-----+
11.0 IANA Considerations 11.0 IANA Considerations
This document defines a number of assigned numbers to be maintained This document defines a number of assigned numbers to be maintained
by the IANA. This section explains the criteria to be used by the by the IANA. This section explains the criteria to be used by the
IANA to assign additional numbers in each of these lists. The IANA to assign additional numbers in each of these lists. The
following subsections describe the assignment policy for the following subsections describe the assignment policy for the
namespaces defined elsewhere in this document. namespaces defined elsewhere in this document.
11.1 AVP 11.1 AVP
As defined in section 4.0, the AVP header contains two fields that As defined in section 4.0, the AVP header contains two fields that
requires IANA namespace management; the AVP Code and Flags field. requires IANA namespace management; the AVP Code and Flags field.
11.1.1 AVP Code 11.1.1 AVP Code
the AVP Code namespace is used to identify attributes. When the
The AVP Code namespace is used to identify attributes. When the
Vendor ID value is set to zero (0), IANA will maintain a registry of 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 assigned AVP codes and in some cases also their values. AVP Codes
0-254 are managed separately as RADIUS Attribute Types [46], while 0-254 are managed separately as RADIUS Attribute Types [RAD TYPE],
the remaining namespace is available for assignment via Specification while the remaining namespace is available for assignment via
Required [12]. Specification Required [IANA].
Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP
header is set to a non-zero value, is for Private Use. header is set to a non-zero value, are for Private Use.
This document defines the AVP Codes 257-274, 276-285, 287, 291-297, This document defines the AVP Codes 257-274, 276-285, 287, 291-297,
480, 482 and 485-486. See section 4.6 for the assignment of the 480, 482 and 485-486. See section 4.6 for the assignment of the
namespace in this specification. namespace in this specification.
11.1.2 AVP Flags 11.1.2 AVP Flags
There are 8 bits in the AVP Flags field of the AVP header, defined in 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 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 ('M'andatory) and bit 6 ('P'rotected). The remaining bits should only
be assigned via a Standards Action [12]. be assigned via a Standards Action [IANA].
11.2 Diameter Header 11.2 Diameter Header
As defined in section 3.0, the Diameter header contains two fields As defined in section 3.0, the Diameter header contains two fields
that require IANA namespace management; Command Code and Command that require IANA namespace management; Command Code and Command
Flags. Flags.
11.2.1 Command Codes 11.2.1 Command Codes
The Command Code namespace is used to identify Diameter commands. The Command Code namespace is used to identify Diameter commands. The
The values 0-255 are reserved for RADIUS backward compatibility, and values 0-255 are reserved for RADIUS backward compatibility, and are
are defined as "RADIUS Packet Type Codes" in [46]. The remaining defined as "RADIUS Packet Type Codes" in [RADTYPE]. The remaining
values are available via Standards Action [12]. values are available via Standards Action [IANA].
Vendor-Specific Command Codes, where the Vendor-Id field in the Vendor-Specific Command Codes, where the Vendor-Id field in the
Diameter header is set to a non-zero value, is for Private Use. Diameter header is set to a non-zero value, are for Private Use.
This document defines the Command Codes 257, 258, 271, 274-275, 280 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 and 282. See section 3.1 for the assignment of the namespace in this
specification. specification.
11.2.2 Command Flags 11.2.2 Command Flags
There are eight bits in the Command Flags field of the Diameter There are eight bits in the Command Flags field of the Diameter
header. This document assigns bit 8 ('R'equest), bit 7 ('P'roxy) and header. This document assigns bit 8 ('R'equest), bit 7 ('P'roxy) and
bit 6 ('E'rror). Bits 1 through 5 MUST only be assigned via a bit 6 ('E'rror). Bits 1 through 5 MUST only be assigned via a
Standards Action [12]. Standards Action [IANA].
11.3 Application Identifiers 11.3 Application Identifiers
As defined in section 2.5, the Application Identifier is used to As defined in section 2.5, the Application Identifier is used to
identify a specific Diameter Application. All values except zero (0) identify a specific Diameter Application. All values except zero (0)
are available for assignment via Standards Action [12]. are available for assignment via Standards Action [IANA].
Vendor-Specific Application Identifiers, encoded in the Vendor- Vendor-Specific Application Identifiers, encoded in the Vendor-
Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to Specific-Application-Id Grouped AVP, with the Vendor-Id AVP set to
the vendor's enterprise number, is for Private Use. the vendor's enterprise number, is for Private Use.
Note that the Diameter protocol is not intended to be extended for Note that the Diameter protocol is not intended to be extended for
any purpose. Any applications defined MUST ensure that they fit any purpose. Any applications defined MUST ensure that they fit
within the existing framework, and that no changes to the base within the existing framework, and that no changes to the base
protocol are required. protocol are required.
11.4 Result-Code AVP Values 11.4 Result-Code AVP Values
As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines
the values 1001, 2001-2002, 3001-3009, 4001-4002 and 5001-5017. the values 1001, 2001-2002, 3001-3009, 4001-4002 and 5001-5017.
All remaining values are available for assignment via IETF Consensus All remaining values are available for assignment via IETF Consensus
[12]. [IANA].
11.5 Accounting-Record-Type AVP Values 11.5 Accounting-Record-Type AVP Values
As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code As defined in Section 9.8.1, the Accounting-Record-Type AVP (AVP Code
480) defines the values 1-4. All remaining values are available for 480) defines the values 1-4. All remaining values are available for
assignment via IETF Consensus [12]. assignment via IETF Consensus [IANA].
11.6 Termination-Cause AVP Values 11.6 Termination-Cause AVP Values
As defined in Section 8.15, the Termination-Cause AVP (AVP Code 295) As defined in Section 8.15, the Termination-Cause AVP (AVP Code 295)
defines the values 1-8. All remaining values are available for defines the values 1-8. All remaining values are available for
assignment via IETF Consensus [12]. assignment via IETF Consensus [IANA].
11.7 Redirect-Host-Usage AVP Values 11.7 Redirect-Host-Usage AVP Values
As defined in Section 6.12, the Redirect-Host-Usage AVP (AVP Code As defined in Section 6.12, the Redirect-Host-Usage AVP (AVP Code
261) defines the values 0-5. All remaining values are available for 261) defines the values 0-5. All remaining values are available for
assignment via IETF Consensus [12]. assignment via IETF Consensus [IANA].
11.8 Session-Server-Failover AVP Values 11.8 Session-Server-Failover AVP Values
As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code As defined in Section 8.18, the Session-Server-Failover AVP (AVP Code
271) defines the values 0-3. All remaining values are available for 271) defines the values 0-3. All remaining values are available for
assignment via IETF Consensus [12]. assignment via IETF Consensus [IANA].
11.9 Session-Binding AVP Values 11.9 Session-Binding AVP Values
As defined in Section 8.17, the Session-Binding AVP (AVP Code 270) As defined in Section 8.17, the Session-Binding AVP (AVP Code 270)
defines the bits 1-4. All remaining bits are available for assignment defines the bits 1-4. All remaining bits are available for assignment
via IETF Consensus [12]. via IETF Consensus [IANA].
11.10 Diameter TCP/SCTP Port Numbers 11.10 Diameter TCP/SCTP Port Numbers
An IANA request has been placed for TCP and SCTP port numbers. The 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 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 2.1 and throughout this document, and will be updated by the RFC
RFC publication process. editor during the RFC publication process.
IANA should also replace "TBD" in sections 4.4 and 5.2 with the port IANA should also replace "TBD" in sections 4.4 and 5.2 with the port
number assigned in section 2.1. number assigned in section 2.1.
11.11 Disconnect-Cause AVP Values 11.11 Disconnect-Cause AVP Values
As defined in Section 5.4.3, the Disconnect-Cause AVP (AVP Code 273) 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 defines the values 0-2. All remaining values are available for
assignment via IETF Consensus [12]. assignment via IETF Consensus [IANA].
11.12 Auth-Request-Type AVP Values 11.12 Auth-Request-Type AVP Values
As defined in Section 8.7, the Auth-Request-Type AVP (AVP Code 274) 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 defines the values 1-3. All remaining values are available for
assignment via IETF Consensus [27]. assignment via IETF Consensus [TCP].
11.13 Auth-Session-State AVP Values 11.13 Auth-Session-State AVP Values
As defined in Section 8.11, the Auth-Session-State AVP (AVP Code 277) 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 defines the values 0-1. All remaining values are available for
assignment via IETF Consensus [27]. assignment via IETF Consensus [TCP].
11.14 Re-Auth-Request-Type AVP Values 11.14 Re-Auth-Request-Type AVP Values
As defined in Section 8.12, the Re-Auth-Request-Type AVP (AVP Code 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 285) defines the values 0-1. All remaining values are available for
assignment via IETF Consensus [27]. assignment via IETF Consensus [TCP].
11.15 NAPTR Service Fields
The registration in the RFC MUST include the following information:
Service Field: The service field being registered. An example for a
new fictitious transport protocol called NCTP might be "AAA+D2N".
Protocol: The specific transport protocol associated with that
service field. This MUST include the name and acronym for the
protocol, along with reference to a document that describes the
transport protocol. For example - "New Connectionless Transport
Protocol (NCTP), RFC 5766".
Name and Contact Information: The name, address, email address and
telephone number for the person performing the registration.
The following values are to be placed into the registry:
Services Field Protocol AAA+D2T
TCP AAAS+D2T TLS over TCP AAA+D2S
SCTP AAAS+D2S TLS over SCTP
12.0 Diameter protocol related configurable parameters 12.0 Diameter protocol related configurable parameters
This section contains the configurable parameters that are found This section contains the configurable parameters that are found
throughout this document: throughout this document:
Diameter Peer Diameter Peer
A Diameter entity MAY communicate with peers that are A Diameter entity MAY communicate with peers that are
statically configured. A statically configured Diameter peer statically configured. A statically configured Diameter peer
would require that either the IP address or the fully qualified would require that either the IP address or the fully qualified
skipping to change at page 114, line 36 skipping to change at page 122, line 12
have a table of Realms Names, and the address of the peer to have a table of Realms Names, and the address of the peer to
which the message must be forwarded to. The routing table MAY which the message must be forwarded to. The routing table MAY
also include a "default route", which is typically used for all also include a "default route", which is typically used for all
messages that cannot be locally processed. messages that cannot be locally processed.
Tc timer Tc timer
The Tc timer controls the frequency that transport connection The Tc timer controls the frequency that transport connection
attempts are done to a peer with whom no active transport attempts are done to a peer with whom no active transport
connection exists. The recommended value is 30 seconds. connection exists. The recommended value is 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 Ti timer controls the frequency the watchdog messages are
to be sent to idle peers. The recommended value is 30 seconds.
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.
13.0 Security Considerations 13.0 Security Considerations
The Diameter base protocol assumes that messages are secured by using The Diameter base protocol assumes that messages are secured by using
either IP Security, or TLS. This security model is acceptable in either IP Security, or TLS. This security model is acceptable in
environments where there are no untrusted third party relay, proxy, environments where there is no untrusted third party relay, proxy, or
or redirect agent. redirect agent.
When third party brokers or redirect agents are used, strong When third party brokers or redirect agents are used, strong
application level security SHOULD be required, such as non- application level security SHOULD be required, such as non-
repudiation. When the communicating peers do require this level of repudiation. When the communicating peers do require this level of
security either for legal or business purposes, the Diameter security either for legal or business purposes, the Diameter
application defined in [11] MAY be used. This security model provides application defined in [CMS] MAY be used. This security model
AVP-level authentication, and the encryption mechanism is designed provides AVP-level authentication, and the encryption mechanism is
such that only the target host has the keying information required to designed such that only the target host has the keying information
decrypt the information. required to decrypt the information.
14.0 References 13.1 IPsec Usage
[1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentica- All Diameter implementations MUST support IPsec ESP [IPsec] in
tion Dial In User Service (RADIUS)", RFC 2865, June 2000. transport mode with with non-null encryption and authentication
algorithms to provide per-packet authentication, integrity protection
and confidentiality, and MUST support the replay protection
mechanisms of IPsec.
[2] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. Diameter implementations MUST support IKE for peer authentication,
negotiation of security associations, and key management, using the
IPsec DOI [IPSECDOI]. Diameter implementations MUST support peer
authentication using a pre-shared key, and MAY support certificate-
based peer authentication using digital signatures. Peer
authentication using the public key encryption methods outlined in
IKE's sections 5.2 and 5.3 [IKE] SHOULD NOT be used.
[3] Postel, "User Datagram Protocol", RFC 768, August 1980. Conformant implementations MUST support both IKE Main Mode and
Aggressive Mode. When pre-shared keys are used for authentication,
IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be
used. When digital signatures are used for authentication, either IKE
Main Mode or IKE Aggressive Mode MAY be used.
[4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload(s) to specify
the certificate authority (or authorities) that are trusted in
accordance with its local policy. IKE negotiators SHOULD use
pertinent certificate revocation checks before accepting a PKI
certificate for use in IKE's authentication procedures.
[5] Kaufman, Perlman, Speciner, "Network Security: Private Communica- The Phase 2 Quick Mode exchanges used to negotiate protection for
tions in a Public World", Prentice Hall, March 1995, ISBN Diameter connections MUST explicitly carry the Identity Payload
0-13-061466-1. fields (IDci and IDcr). The DOI provides for several types of
identification data. However, when used in conformant
implementations, each ID Payload MUST carry a single IP address and a
single non-zero port number, and MUST NOT use the IP Subnet or IP
Address Range formats. This allows the Phase 2 security association
to correspond to specific TCP and SCTP connections.
[6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message Since IPsec acceleration hardware may only be able to handle a
Authentication", RFC 2104, January 1997. limited number of active IKE Phase 2 SAs, Phase 2 delete messages may
be sent for idle SAs, as a means of keeping the number of active
Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete
message SHOULD NOT be interpreted as a reason for tearing down a
Diameter connection. Rather, it is preferable to leave the connection
up, and if additional traffic is sent on it, to bring up another IKE
Phase 2 SA to protect it. This avoids the potential for continually
bringing connections up and down.
[7] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Appli- 13.2 TLS Usage
cation", draft-ietf-aaa-diameter-nasreq-08.txt, IETF work in
progress, November 2001.
[8] Aboba, Beadles "The Network Access Identifier." RFC 2486. January A Diameter node that initiates a connection to another Diameter node
1999. acts as a TLS client according to [TLS], and a Diameter node that
accepts a connection acts as a TLS server. Diameter nodes
implementing TLS for security MUST mutually authenticate as part of
TLS session establishment. In order to ensure mutual authentication,
the Diameter node acting as TLS server must request a certificate
from the Diameter node acting as TLS client, and the Diameter node
acting as TLS client MUST be prepared to supply a certificate on
request.
[10] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", draft- When Diameter uses TLS, it MUST have the same dNSName field
ietf-aaa-diameter-mobileip-08.txt, IETF work in progress, November requirements as the Diameter CMS Security Application [CMS] listed in
2001. section 3.2.
[11] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security applica- Diameter nodes MUST be able to negotiate the following TLS cipher
tion", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in suites:
progress, November 2001.
[12] Narten, Alvestrand,"Guidelines for Writing an IANA Considerations TLS_RSA_WITH_RC4_128_MD5
Section in RFCs", BCP 26, RFC 2434, October 1998 TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
[13] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- Diameter nodes MAY negotiate other TLS cipher suites.
els", BCP 14, RFC 2119, March 1997.
[14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key 14.0 References
Infrastructure Online Certificate Status Protocol (OCSP)", RFC
2560, June 1999.
[15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, 14.1 Normative
November 1998.
[16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 2373, [AAATRANS] B. Aboba, J. Wood, "Authentication, Authorization and
July 1998. Accounting (AAA) Transport Profile", draft-ietf-aaa-
transport-04.txt, IETF Work in Progress, June 2001.
[17] ISI, "Internet Protocol", RFC 791, September 1981. [ASSIGNNO] Reynolds, Postel, "Assigned Numbers", RFC 1700, October
1994.
[18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security
IPv6 and OSI, RFC 2030, October 1996. application", draft-ietf-aaa-diameter-cms-sec-03.txt,
IETF work in progress, November 2001.
[19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc- [DIFFSERV] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of
ture Certificate and CRL Profile", RFC 2459, January 1999. the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers," RFC 2474, December 1998.
[20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC [DIFFSERVAF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured
2477, January 1999. Forwarding PHB Group," RFC 2597, June 1999.
[21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access [DIFFSERVEF] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forˇ
Server Protocols", RFC 3169, September 2001. warding PHB", RFC 2598, June 1999.
[22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", [DNSSRV] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for speciˇ
RFC 3141, June 2001. fying the location of services (DNS SRV)", RFC 2782,
February 2000.
[23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho- [EAP] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentiˇ
rization, and Accounting Requirements". RFC 2977. October 2000. cation Protocol (EAP)." RFC 2284, March 1998.
[24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC [FLOATPOINT] Institute of Electrical and Electronics Engineers, "IEEE
2279, January 1998. Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
Standard 754-1985, August 1985.
[25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication Pro- [IANA] Narten, Alvestrand, "Guidelines for Writing an IANA Conˇ
tocol (EAP)." RFC 2284, March 1998. siderations Section in RFCs", BCP 26, RFC 2434, October
1998
[26] R. Stewart et al., "Stream Control Transmission Protocol". RFC [IANAWEB] IANA, "Number assignment", http://www.iana.org
2960. October 2000.
[27] Postel, J. "Transmission Control Protocol", RFC 793, January 1981. [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Pro- [IPSECDOI] D. Piper, "The Internet IP Security Domain of Interpretaˇ
tocol, Version 2", RFC 2165, June 1999. tion for ISAKMP", RFC 2407, November 1998.
[29] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, "Uniform [IPV4] ISI, "Internet Protocol", RFC 791, September 1981.
Resource Identifiers (URI): Generic Syntax". RFC 2396, August 1998.
[30] Institute of Electrical and Electronics Engineers, "IEEE Standard [IPV6] Hinden, Deering, "IP Version 6 Addressing Architecture",
for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, RFC 2373, July 1998.
August 1985.
[31] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
ABNF", RFC 2234, November 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[32] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Service: [NAI] Aboba, Beadles "The Network Access Identifier." RFC 2486.
Schemes", RFC 2609, June 1999. January 1999.
[33] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the [NAPTR] M. Mealling and R. Daniel, "The naming authority pointer
location of services (DNS SRV)", RFC 2782, February 2000. (NAPTR) DNS resource record," Request for Comments 2915,
Internet Engineering Task Force, Sept. 2000.
[34] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, [RADTYPE] IANA, "RADIUS Types", http://www.isi.edu/in-
March 1999. notes/iana/assignments/radius-types
[35] D. Eastlake, "DNS Security Operational Considerations", RFC 2541, [SCTP] R. Stewart et al., "Stream Control Transmission Protoˇ
March 1999. col". RFC 2960. October 2000.
[36] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s )", [SLP] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service
RFC 2931, September 2000. Location Protocol, Version 2", RFC 2165, June 1999.
[37] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro- [SNTP] Mills, "Simple Network Time Protocol (SNTP) Version 4 for
tocol", RFC 2401, November 1998. IPv4, IPv6 and OSI, RFC 2030, October 1996.
[38] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, Jan- [TCP] Postel, J. "Transmission Control Protocol", RFC 793, Janˇ
uary 1999. uary 1981.
[39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. [TEMPLATE] E. Guttman, C. Perkins, J. Kempf, "Service Templates and
677-680. Service: Schemes", RFC 2609, June 1999.
[40] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting Man- [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC
agement", RFC 2975, October 2000. 2246, January 1999.
[41] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compres- [TLSSCTP] M. Tuexen, et al. "TLS over SCTP" IETF Work in Progress,
sion Protocol (IPComp)", RFC 2393, December 1998. November 2001.
[42] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 51, [URI] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter,
July 1994. "Uniform Resource Identifiers (URI): Generic Syntax". RFC
2396, August 1998.
[43] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO
Implementations", RFC 2194, September 1997. 10646", RFC 2279, January 1998.
[44] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementation 14.2 Non-Normative
in Roaming", RFC 2607, June 1999. [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Speciˇ
fications: ABNF", RFC 2234, November 1997.
[45] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [ACCMGMT] B. Aboba, J. Arkko, D. Harrington. "Introduction to
Accounting Management", RFC 2975, October 2000.
[46] IANA, "RADIUS Types", http://www.isi.edu/in-notes/iana/assign- [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements
ments/radius-types for AAA", RFC 3141, June 2001.
[47] IANA, "Number assignment", http://www.iana.org [DIAMMIP] P. Calhoun, C. Perkins, "Diameter Mobile IP Application",
draft-ietf-aaa-diameter-mobileip-08.txt, IETF work in
progress, November 2001.
[48] P. V. Mockapetris, "Domain names - implementation and specifica- [IPComp] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payˇ
tion," RFC 1035, November 1987. load Compression Protocol (IPComp)", RFC 2393, December
1998.
[49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Dif- [MIPV4] C. Perkins, Editor. IP Mobility Support. RFC 2002,
ferentiated Services Field (DS Field) in the IPv4 and IPv6 Head- October 1996.
ers," RFC 2474, December 1998.
[50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authenticaˇ
PHB Group," RFC 2597, June 1999. tion, Authorization, and Accounting Requirements". RFC
2977. October 2000.
[51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", [NASREQ] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASˇ
RFC 2598, June 1999. REQ Application", draft-ietf-aaa-diameter-nasreq-08.txt,
IETF work in progress, November 2001.
[52] B. Aboba, J. Wood, "Authentication, Authorization and Accounting [NASCRIT] M. Beadles, D. Mitton, "Criteria for Evaluating Network
(AAA) Transport Profile", draft-ietf-aaa-transport-04.txt, IETF Access Server Protocols", RFC 3169, September 2001.
Work in Progress, June 2001.
15.0 Acknowledgements [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC
1661, STD 51, July 1994.
[PROXYCHAIN] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[ROAMCRIT] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Proˇ
tocols", RFC 2477, January 1999.
[SECARCH] S. Kent, R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
15.0 Acknowledgements
The authors would like to thank Nenad Trifunovic, Tony Johansson and The authors would like to thank Nenad Trifunovic, Tony Johansson and
Pankaj Patel for their participation in the pre-IETF Document Reading Pankaj Patel for their participation in the pre-IETF Document Reading
Party. Allison Mankin's, Jonathan Wood and Bernard Aboba's assis- Party. Allison Mankin, Jonathan Wood and Bernard Aboba provided
tance was invaluable in working out transport issues, and similarly invaluable assistance in working out transport issues, and similarly
with Steven Bellovin's help in the security area. with Steven Bellovin in the security area.
Paul Funk and David Mitton were instrumental in getting the Peer Paul Funk and David Mitton were instrumental in getting the Peer
State Machine correct, and our deep thanks go to them for their time. State Machine correct, and our deep thanks go to them for their time.
Text in this document was also provided by Paul Funk, Mark Eklund, Text in this document was also provided by Paul Funk, Mark Eklund,
Mark Jones and Dave Spence. Jacques Caron provided many great com- Mark Jones and Dave Spence. Jacques Caron provided many great comˇ
ments as a result of a thorough review of the spec. ments as a result of a thorough review of the spec.
The authors would also like to acknowledge the following people for The authors would also like to acknowledge the following people for
their contribution in the development of the Diameter protocol: their contribution in the development of the Diameter protocol:
William Bulley, Stephen Farrell, David Frascone, Daniel C. Fox, Lol Allan C. Rubens, Haseeb Akhtar, William Bulley, Stephen Farrell,
Grant, Ignacio Goyret, Nancy Greene, Peter Heitman, Fredrik Johans- David Frascone, Daniel C. Fox, Lol Grant, Ignacio Goyret, Nancy
son, Mark Jones, Martin Julien, Paul Krumviede, Fergal Ladley, Ryan Greene, Peter Heitman, Fredrik Johansson, Mark Jones, Martin Julien,
Moats, Victor Muslin, Kenneth Peirce, John Schnizlein, Sumit Vakil, Paul Krumviede, Fergal Ladley, Ryan Moats, Victor Muslin, Kenneth
John R. Vollbrecht and Jeff Weisberg Peirce, John Schnizlein, Sumit Vakil, John R. Vollbrecht and Jeff
Weisberg
Finally, Pat Calhoun would like to thank Sun Microsystems since most Finally, Pat Calhoun would like to thank Sun Microsystems since most
of the effort put into this document was done while he was in their of the effort put into this document was done while he was in their
employ. employ.
16.0 Authors' Addresses 16.0 Authors' Addresses
Questions about this memo can be directed to: Questions about this memo can be directed to:
Pat R. Calhoun Pat R. Calhoun
Black Storm Networks Black Storm Networks
250 Cambridge Avenue, Suite 200 250 Cambridge Avenue, Suite 200
Palo Alto, California, 94306 Palo Alto, California, 94306
USA USA
Phone: +1 650-617-2932 Phone: +1 650-617-2932
Fax: +1 650-786-6445 Fax: +1 650-786-6445
E-mail: pcalhoun@diameter.org E-mail: pcalhoun@diameter.org
Haseeb Akhtar
Wireless Technology Labs
Nortel Networks
2221 Lakeside Blvd.
Richardson, TX 75082-4399
USA
Phone: +1 972-684-8850
E-Mail: haseeb@nortelnetworks.com
Jari Arkko Jari Arkko
Oy LM Ericsson Ab Oy LM Ericsson Ab
02420 Jorvas 02420 Jorvas
Finland Finland
Phone: +358 40 5079256 Phone: +358 40 5079256
E-Mail: Jari.Arkko@ericsson.com E-Mail: Jari.Arkko@ericsson.com
Erik Guttman Erik Guttman
Solaris Advanced Development Solaris Advanced Development
Sun Microsystems, Inc. Sun Microsystems, Inc.
Eichhoelzelstr. 7 Eichhoelzelstr. 7
74915 Waibstadt 74915 Waibstadt
Germany Germany
Phone: +49-7263-911-701 Phone: +49-7263-911-701
E-mail: erik.guttman@germany.sun.com E-mail: erik.guttman@germany.sun.com
Allan C. Rubens
Tut Systems, Inc.
220 E. Huron, Suite 260
Ann Arbor, MI 48104
USA
Phone: +1 734-995-1697
E-Mail: arubens@tutsys.com
Glen Zorn Glen Zorn
Cisco Systems, Inc. Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500 500 108th Avenue N.E., Suite 500
Bellevue, WA 98004 Bellevue, WA 98004
USA USA
Phone: +1 425 438 8218 Phone: +1 425 438 8218
John Loughney
Nokia Research Center
It„merenkatu 11-13
00180 Helsinki
Finland
Phone: +358 50 483 6242
E-mail: john.Loughney@nokia.com
17.0 Full Copyright Statement 17.0 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this docu- included on all such copies and derivative works. However, this docuˇ
ment itself may not be modified in any way, such as by removing the ment itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop- Internet organizations, except as needed for the purpose of developˇ
ing Internet standards in which case the procedures for copyrights ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English. The lim- required to translate it into languages other than English. The limˇ
ited permissions granted above are perpetual and will not be revoked ited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns. This document by the Internet Society or its successors or assigns. This document
and the information contained herein is provided on an "AS IS" basis and the information contained herein is provided on an "AS IS" basis
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISˇ
CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
18.0 Expiration Date 18.0 Expiration Date
This memo is filed as <draft-ietf-aaa-diameter-08.txt> and expires in This memo is filed as <draft-ietf-aaa-diameter-10.txt> and expires in
May 2002. September 2002.
Appendix A. Diameter Service Template Appendix A. Diameter Service Template
The following service template describes the attributes used by Diam- The following service template describes the attributes used by Diamˇ
eter servers to advertise themselves. This simplifies the process of eter servers to advertise themselves. This simplifies the process of
selecting an appropriate server to communicate with. A Diameter selecting an appropriate server to communicate with. A Diameter
client can request specific Diameter servers based on characteristics client can request specific Diameter servers based on characteristics
of the Diameter service desired (for example, an AAA server to use of the Diameter service desired (for example, an AAA server to use
for accounting.) for accounting.)
Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com>
Language of service template: en Language of service template: en
Security Considerations: Security Considerations:
Diameter clients and servers use various cryptographic mechanisms Diameter clients and servers use various cryptographic mechanisms
to protect communication integrity, confidentiality as well as to protect communication integrity, confidentiality as well as
perform end-point authentication. It would thus be difficult if perform end-point authentication. It would thus be difficult if
not impossible for an attacker to advertise itself using SLPv2 and not impossible for an attacker to advertise itself using SLPv2 and
pose as a legitimate Diameter peer without proper preconfigured pose as a legitimate Diameter peer without proper preconfigured
secrets or cryptographic keys. Still, as Diameter services are secrets or cryptographic keys. Still, as Diameter services are
vital for network operation it is important to use SLPv2 authenti- vital for network operation it is important to use SLPv2 authentiˇ
cation to prevent an attacker from modifying or eliminating ser- cation to prevent an attacker from modifying or eliminating serˇ
vice advertisements for legitimate Diameter servers. vice advertisements for legitimate Diameter servers.
Template text: Template text:
-------------------------template begins here----------------------- -------------------------template begins here-----------------------
template-type=service:diameter template-type=service:diameter
template-version=0.0 template-version=0.0
template-description= template-description=
The Diameter protocol is defined by draft-ietf-aaa-diameter-07.txt The Diameter protocol is defined by draft-ietf-aaa-diameter-10.txt
template-url-syntax= template-url-syntax=
url-path= ; The Diameter URL format is described in section 4.4. url-path= ; The Diameter URL format is described in section 2.9.
; Example: 'aaa://aaa.example.com:1812;transport=tcp ; Example: 'aaa://aaa.abc.com:1812;transport=tcp
supported-auth-applications= string L M supported-auth-applications= string L M
# This attribute lists the Diameter applications supported by the # This attribute lists the Diameter applications supported by the
# AAA implementation. The applications currently defined are: # AAA implementation. The applications currently defined are:
# Application Name Defined by # Application Name Defined by
# ---------------- ----------------------------------- # ---------------- -----------------------------------
# NASREQ draft-ietf-aaa-diameter-nasreq-07.txt # NASREQ draft-ietf-aaa-diameter-nasreq-08.txt
# MobileIP draft-ietf-aaa-diameter-mobileip-07.txt # MobileIP draft-ietf-aaa-diameter-mobileip-08.txt
# CMS Security draft-ietf-aaa-diameter-cms-sec-02.txt # CMS Security draft-ietf-aaa-diameter-cms-sec-03.txt
# #
# Notes: # Notes:
# . Diameter implementations support one or more applications. # . Diameter implementations support one or more applications.
# . Additional applications may be defined in the future. # . Additional applications may be defined in the future.
# An updated service template will be created at that time. # An updated service template will be created at that time.
# #
NASREQ,MobileIP,CMS Security NASREQ,MobileIP,CMS Security
supported-acct-applications= string L M supported-acct-applications= string L M
# This attribute lists the Diameter applications supported by the # This attribute lists the Diameter applications supported by the
# AAA implementation. The applications currently defined are: # AAA implementation. The applications currently defined are:
# Application Name Defined by # Application Name Defined by
# ---------------- ----------------------------------- # ---------------- -----------------------------------
# NASREQ draft-ietf-aaa-diameter-nasreq-07.txt # NASREQ draft-ietf-aaa-diameter-nasreq-08.txt
# MobileIP draft-ietf-aaa-diameter-mobileip-07.txt # MobileIP draft-ietf-aaa-diameter-mobileip-08.txt
# CMS Security draft-ietf-aaa-diameter-cms-sec-02.txt # CMS Security draft-ietf-aaa-diameter-cms-sec-03.txt
# #
# Notes: # Notes:
# . Diameter implementations support one or more applications. # . Diameter implementations support one or more applications.
# . Additional applications may be defined in the future. # . Additional applications may be defined in the future.
# An updated service template will be created at that time. # An updated service template will be created at that time.
# #
NASREQ,MobileIP,CMS Security NASREQ,MobileIP,CMS Security
supported-transports= string L M supported-transports= string L M
SCTP SCTP
# This attribute lists the supported transports that the Diameter # This attribute lists the supported transports that the Diameter
# implementation accepts. Note that a compliant Diameter # implementation accepts. Note that a compliant Diameter
# implementation MUST support SCTP, though it MAY support other # implementation MUST support SCTP, though it MAY support other
# transports, too. # transports, too.
SCTP,TCP SCTP,TCP
-------------------------template ends here----------------------- -------------------------template ends here-----------------------
Appendix B. NAPTR Example
As an example, consider a client that wishes to resolve aaa:ex.com.
The client performs a NAPTR query for that domain, and the following
NAPTR records are returned:
;; order pref flags service regexp replacement
IN NAPTR 20 50 "s" "AAAS+D2S" "" _diameˇ
ters._sctp.ex.com. IN NAPTR 50 50 "s" "AAA+D2S" ""
_diameter._sctp.ex.com. IN NAPTR 90 50 "s" "AAAS+D2T"
"" _diameters._tcp.ex.com. IN NAPTR 100 50 "s" "AAA+D2T"
"" _aaa._tcp.ex.com
This indicates that the server supports TLS over SCTP, SCTP, TLS over
TCP, and TCP, in that order. If the client supports TLS over SCTP,
SCTP will be used, targeted to a host determined by an SRV lookup of
_diameters._sctp.ex.com. That lookup would return:
;; Priority Weight Port Target
IN SRV 0 1 5060 server1.ex.com IN SRV 0 2
5060 server2.ex.com
Appendix C. Duplicate Detection
As described in section 9.4, accounting record duplicate detection is
based on the session identifiers. Duplicates can appear for various
reasons:
- Failover to an alternate server. Where we close to real-time
performance is expected, failover tresholds need to be kept low
and this may lead to a relatively large likelihood of duplicates.
- A crash of a client at the time it just had managed to send a
record from a non-volatile memory would likely cause the same
record to be sent soon after the client has rebooted.
- Duplicates received from RADIUS gateways.
- Implementation problems and misconfiguration.
In some cases the Diameter accounting server can delay the duplicate
detection and accounting record processing until a post-processing
phase takes place. At that time records are likely to be sorted
according to the User-Name contained in them and duplicate eliminaˇ
tion is easy in this case.
In other situations it may be necessary to perform real-time dupliˇ
cate detection, e.g. when the credit limits or fraud attempts are
being monitored in real time.
In general, only the duplicate generation at failover case is someˇ
thing that can be reliably detected by the Diameter client. The
Diameter server is therefore responsible for the duplicate detection
process. When real-time duplicate detection is required, this implies
a database-like search functionality to find duplicate records.
Implementors are advised, however, that there exists ways to avoid
expensive all-record searches. For instance, it can be usually
safely assumed that duplicates appear within a time window of longest
imaginable network partition, perhaps a day as an example. So only
records within this time window need to be looked at. Secondly, hashˇ
ing techniques or other schemes may be used to eliminate the need to
do a full search even in this set except for rare cases.
 End of changes. 424 change blocks. 
960 lines changed or deleted 1220 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/