draft-ietf-dime-rfc3588bis-01.txt   draft-ietf-dime-rfc3588bis-02.txt 
DIME V. Fajardo, Ed. DIME V. Fajardo, Ed.
Internet-Draft Toshiba America Research Internet-Draft Toshiba America Research
Intended status: Standards Track J. Loughney Intended status: Standards Track J. Loughney
Expires: August 2, 2007 Nokia Research Center Expires: September 4, 2007 Nokia Research Center
January 29, 2007 March 3, 2007
Diameter Base Protocol Diameter Base Protocol
draft-ietf-dime-rfc3588bis-01.txt draft-ietf-dime-rfc3588bis-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2, 2007. This Internet-Draft will expire on September 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Diameter base protocol is intended to provide an Authentication, The Diameter base protocol is intended to provide an Authentication,
Authorization and Accounting (AAA) framework for applications such as Authorization and Accounting (AAA) framework for applications such as
network access or IP mobility. Diameter is also intended to work in network access or IP mobility. Diameter is also intended to work in
skipping to change at page 2, line 37 skipping to change at page 2, line 37
1.2.5. Application Authentication Procedures . . . . . . . 15 1.2.5. Application Authentication Procedures . . . . . . . 15
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 16 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 16
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 23 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 23
2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 24 2.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 25 2.1.1. SCTP Guidelines . . . . . . . . . . . . . . . . . . 25
2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 25 2.2. Securing Diameter Messages . . . . . . . . . . . . . . . 25
2.3. Diameter Application Compliance . . . . . . . . . . . . . 25 2.3. Diameter Application Compliance . . . . . . . . . . . . . 25
2.4. Application Identifiers . . . . . . . . . . . . . . . . . 26 2.4. Application Identifiers . . . . . . . . . . . . . . . . . 26
2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 26 2.5. Connections vs. Sessions . . . . . . . . . . . . . . . . 26
2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 27 2.6. Peer Table . . . . . . . . . . . . . . . . . . . . . . . 27
2.7. Realm-Based Routing Table . . . . . . . . . . . . . . . . 28 2.7. Routing Table . . . . . . . . . . . . . . . . . . . . . . 28
2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 30 2.8. Role of Diameter Agents . . . . . . . . . . . . . . . . . 30
2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 31 2.8.1. Relay Agents . . . . . . . . . . . . . . . . . . . . 31
2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 32 2.8.2. Proxy Agents . . . . . . . . . . . . . . . . . . . . 32
2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 32 2.8.3. Redirect Agents . . . . . . . . . . . . . . . . . . 32
2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 33 2.8.4. Translation Agents . . . . . . . . . . . . . . . . . 33
2.9. End-to-End Security Framework . . . . . . . . . . . . . . 34 2.9. End-to-End Security Framework . . . . . . . . . . . . . . 34
2.10. Diameter Path Authorization . . . . . . . . . . . . . . . 35 2.10. Diameter Path Authorization . . . . . . . . . . . . . . . 35
3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 37 3. Diameter Header . . . . . . . . . . . . . . . . . . . . . . . 37
3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 40 3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 40
3.2. Command Code ABNF specification . . . . . . . . . . . . . 41 3.2. Command Code ABNF specification . . . . . . . . . . . . . 41
skipping to change at page 3, line 15 skipping to change at page 3, line 15
4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 48 4.3. Derived AVP Data Formats . . . . . . . . . . . . . . . . 48
4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 56 4.4. Grouped AVP Values . . . . . . . . . . . . . . . . . . . 56
4.4.1. Example AVP with a Grouped Data type . . . . . . . . 57 4.4.1. Example AVP with a Grouped Data type . . . . . . . . 57
4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 60 4.5. Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 60
5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 63 5. Diameter Peers . . . . . . . . . . . . . . . . . . . . . . . 63
5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 63 5.1. Peer Connections . . . . . . . . . . . . . . . . . . . . 63
5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 63 5.2. Diameter Peer Discovery . . . . . . . . . . . . . . . . . 63
5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 66 5.3. Capabilities Exchange . . . . . . . . . . . . . . . . . . 66
5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 67 5.3.1. Capabilities-Exchange-Request . . . . . . . . . . . 67
5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 68 5.3.2. Capabilities-Exchange-Answer . . . . . . . . . . . . 68
5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 68 5.3.3. Vendor-Id AVP . . . . . . . . . . . . . . . . . . . 69
5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 69 5.3.4. Firmware-Revision AVP . . . . . . . . . . . . . . . 69
5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 69 5.3.5. Host-IP-Address AVP . . . . . . . . . . . . . . . . 69
5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 69 5.3.6. Supported-Vendor-Id AVP . . . . . . . . . . . . . . 69
5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 69 5.3.7. Product-Name AVP . . . . . . . . . . . . . . . . . . 70
5.4. Disconnecting Peer connections . . . . . . . . . . . . . 69 5.4. Disconnecting Peer connections . . . . . . . . . . . . . 70
5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 70 5.4.1. Disconnect-Peer-Request . . . . . . . . . . . . . . 70
5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 70 5.4.2. Disconnect-Peer-Answer . . . . . . . . . . . . . . . 71
5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 71 5.4.3. Disconnect-Cause AVP . . . . . . . . . . . . . . . . 71
5.5. Transport Failure Detection . . . . . . . . . . . . . . . 71 5.5. Transport Failure Detection . . . . . . . . . . . . . . . 72
5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 71 5.5.1. Device-Watchdog-Request . . . . . . . . . . . . . . 72
5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 72 5.5.2. Device-Watchdog-Answer . . . . . . . . . . . . . . . 72
5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 72 5.5.3. Transport Failure Algorithm . . . . . . . . . . . . 73
5.5.4. Failover and Failback Procedures . . . . . . . . . . 72 5.5.4. Failover and Failback Procedures . . . . . . . . . . 73
5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 73 5.6. Peer State Machine . . . . . . . . . . . . . . . . . . . 73
5.6.1. Incoming connections . . . . . . . . . . . . . . . . 75 5.6.1. Incoming connections . . . . . . . . . . . . . . . . 76
5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 76 5.6.2. Events . . . . . . . . . . . . . . . . . . . . . . . 76
5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 77 5.6.3. Actions . . . . . . . . . . . . . . . . . . . . . . 77
5.6.4. The Election Process . . . . . . . . . . . . . . . . 79 5.6.4. The Election Process . . . . . . . . . . . . . . . . 79
5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 79 5.6.5. Capabilities Update . . . . . . . . . . . . . . . . 79
6. Diameter message processing . . . . . . . . . . . . . . . . . 80 6. Diameter message processing . . . . . . . . . . . . . . . . . 80
6.1. Diameter Request Routing Overview . . . . . . . . . . . . 80 6.1. Diameter Request Routing Overview . . . . . . . . . . . . 80
6.1.1. Originating a Request . . . . . . . . . . . . . . . 81 6.1.1. Originating a Request . . . . . . . . . . . . . . . 81
6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 82 6.1.2. Sending a Request . . . . . . . . . . . . . . . . . 82
6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 82 6.1.3. Receiving Requests . . . . . . . . . . . . . . . . . 82
6.1.4. Processing Local Requests . . . . . . . . . . . . . 82 6.1.4. Processing Local Requests . . . . . . . . . . . . . 82
skipping to change at page 5, line 14 skipping to change at page 5, line 14
8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 126 8.15. Termination-Cause AVP . . . . . . . . . . . . . . . . . . 126
8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 127 8.16. Origin-State-Id AVP . . . . . . . . . . . . . . . . . . . 127
8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 128 8.17. Session-Binding AVP . . . . . . . . . . . . . . . . . . . 128
8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 128 8.18. Session-Server-Failover AVP . . . . . . . . . . . . . . . 128
8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 129 8.19. Multi-Round-Time-Out AVP . . . . . . . . . . . . . . . . 129
8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 129 8.20. Class AVP . . . . . . . . . . . . . . . . . . . . . . . . 129
8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 130 8.21. Event-Timestamp AVP . . . . . . . . . . . . . . . . . . . 130
9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 131 9. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 131 9.1. Server Directed Model . . . . . . . . . . . . . . . . . . 131
9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 132 9.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 132
9.3. Application document requirements . . . . . . . . . . . . 132 9.3. Accounting Application Extension and Requirements . . . . 132
9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 132 9.4. Fault Resilience . . . . . . . . . . . . . . . . . . . . 133
9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 133 9.5. Accounting Records . . . . . . . . . . . . . . . . . . . 134
9.6. Correlation of Accounting Records . . . . . . . . . . . . 134 9.6. Correlation of Accounting Records . . . . . . . . . . . . 135
9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 135 9.7. Accounting Command-Codes . . . . . . . . . . . . . . . . 135
9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 135 9.7.1. Accounting-Request . . . . . . . . . . . . . . . . . 135
9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 136 9.7.2. Accounting-Answer . . . . . . . . . . . . . . . . . 136
9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 137 9.8. Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 137
9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 137 9.8.1. Accounting-Record-Type AVP . . . . . . . . . . . . . 137
9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 138 9.8.2. Acct-Interim-Interval . . . . . . . . . . . . . . . 138
9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 138 9.8.3. Accounting-Record-Number AVP . . . . . . . . . . . . 139
9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 139 9.8.4. Acct-Session-Id AVP . . . . . . . . . . . . . . . . 139
9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 139 9.8.5. Acct-Multi-Session-Id AVP . . . . . . . . . . . . . 139
9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 139 9.8.6. Accounting-Sub-Session-Id AVP . . . . . . . . . . . 140
9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 139 9.8.7. Accounting-Realtime-Required AVP . . . . . . . . . . 140
10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 141 10. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . 141
10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 141 10.1. Base Protocol Command AVP Table . . . . . . . . . . . . . 141
10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 142 10.2. Accounting AVP Table . . . . . . . . . . . . . . . . . . 142
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 144
11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 144 11.1. AVP Header . . . . . . . . . . . . . . . . . . . . . . . 144
11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 144 11.1.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . 144
11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 145 11.1.2. AVP Flags . . . . . . . . . . . . . . . . . . . . . 145
11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 145 11.2. Diameter Header . . . . . . . . . . . . . . . . . . . . . 145
11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 145 11.2.1. Command Codes . . . . . . . . . . . . . . . . . . . 145
11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 146 11.2.2. Command Flags . . . . . . . . . . . . . . . . . . . 146
skipping to change at page 14, line 23 skipping to change at page 14, line 23
requiring new AVPs, addition of EAP methods does not require the requiring new AVPs, addition of EAP methods does not require the
creation of a new authentication application. creation of a new authentication application.
Creation of a new application should be viewed as a last resort. An Creation of a new application should be viewed as a last resort. An
implementation MAY add arbitrary non-mandatory AVPs to any command implementation MAY add arbitrary non-mandatory AVPs to any command
defined in an application, including vendor-specific AVPs without defined in an application, including vendor-specific AVPs without
needing to define a new application. Please refer to Section 11.1.1 needing to define a new application. Please refer to Section 11.1.1
for details. for details.
In order to justify allocation of a new application identifier, In order to justify allocation of a new application identifier,
Diameter applications MUST define one Command Code, or add new Diameter applications MUST define one Command Code, add new mandatory
mandatory AVPs to the ABNF. AVPs to the ABNF or significantly change the state machine or
processing rules of an existing application.
The expected AVPs MUST be defined in an ABNF [RFC2234] grammar (see The expected AVPs MUST be defined in an ABNF [RFC2234] grammar (see
Section 3.2). If the Diameter application has accounting Section 3.2). If the Diameter application has accounting
requirements, it MUST also specify the AVPs that are to be present in requirements, it MUST also specify the AVPs that are to be present in
the Diameter Accounting messages (see Section 9.3). However, just the Diameter Accounting messages (see Section 9.3). However, just
because a new authentication application id is required, does not because a new authentication application id is required, does not
imply that a new accounting application id is required. imply that a new accounting application id is required.
When possible, a new Diameter application SHOULD reuse existing When possible, a new Diameter application SHOULD reuse existing
Diameter AVPs, in order to avoid defining multiple AVPs that carry Diameter AVPs, in order to avoid defining multiple AVPs that carry
skipping to change at page 19, line 44 skipping to change at page 19, line 44
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 Agent or Relay Relay Agent or Relay
Relays forward requests and responses based on routing-related Relays forward requests and responses based on routing-related
AVPs and realm routing table entries. Since relays do not make AVPs and routing table entries. Since relays do not make policy
policy decisions, they do not examine or alter non-routing AVPs. decisions, 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 application or message type. handling any Diameter application or message type. Since relays
make decisions based on information in routing AVPs and realm
Since relays make decisions based on information in routing AVPs forwarding tables they do not keep state on NAS resource usage or
and realm forwarding tables they do not keep state on NAS resource sessions in progress.
usage or sessions 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 transiting 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
skipping to change at page 27, line 37 skipping to change at page 27, line 37
that Diameter messages pertaining to the session, both application that Diameter messages pertaining to the session, both application
specific and those that are defined in this document such as ASR/ASA, specific and those that are defined in this document such as ASR/ASA,
RAR/RAA and STR/STA MUST carry the application identifier of the RAR/RAA and STR/STA MUST carry the application identifier of the
application. Diameter messages pertaining to peer connection application. Diameter messages pertaining to peer connection
establishment and maintenance such as CER/CEA, DWR/DWA and DPR/DPA establishment and maintenance such as CER/CEA, DWR/DWA and DPR/DPA
MUST carry an application id of zero (0). MUST carry an application id of zero (0).
2.6. 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 by the Routing Table. A Peer Table entry contains the following
following fields: fields:
Host identity Host identity
Following the conventions described for the DiameterIdentity Following the conventions described for the DiameterIdentity
derived AVP data format in Section 4.4. This field contains the derived AVP data format in Section 4.4. This field contains the
contents of the Origin-Host (Section 6.3) AVP found in the CER or contents of the Origin-Host (Section 6.3) AVP found in the CER or
CEA message. CEA message.
StatusT StatusT
skipping to change at page 28, line 23 skipping to change at page 28, line 23
entries are to be either refreshed, or expired. entries are to be either refreshed, or expired.
TLS Enabled TLS Enabled
Specifies whether TLS is to be used when communicating with the Specifies whether TLS is to be used when communicating with the
peer. peer.
Additional security information, when needed (e.g., keys, Additional security information, when needed (e.g., keys,
certificates) certificates)
2.7. Realm-Based Routing Table 2.7. 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). A Realm commonly known as the Routing Table (see Section 12). A Routing
Routing Table Entry contains the following fields: Table Entry contains the following fields:
Realm Name Realm Name
This is the field that is typically used as a primary key in the This is the field that is typically used as a primary key in the
routing table lookups. Note that some implementations perform routing table lookups. Note that some implementations perform
their lookups based on longest-match-from-the-right on the realm their lookups based on longest-match-from-the-right on the realm
rather than requiring an exact match. rather than requiring an exact match.
Application Identifier Application Identifier
skipping to change at page 31, line 25 skipping to change at page 31, line 25
be stateless for others. A Diameter implementation MAY act as one be stateless for others. A Diameter implementation MAY act as 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.8.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 nodes 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 messages (e.g., Destination-Realm). This routing decision is
performed using a list of supported realms, and known peers. This is performed using a list of supported realms, and known peers. This is
known as the Realm Routing Table, as is defined further in Section known as the Routing Table, as is defined further in Section 2.7.
2.7.
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.
skipping to change at page 66, line 36 skipping to change at page 66, line 36
sent to a peer. sent to a peer.
A receiver of a Capabilities-Exchange-Req (CER) message that does not A receiver of a Capabilities-Exchange-Req (CER) message that does 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.4) MUST be interpreted advertising itself as a Relay (see Section 2.4) MUST be interpreted
as having common applications with the peer. as having common applications with the peer.
The receiver of the Capabilities-Exchange-Request (CER) MUST
determine common applications by computing the intersection of its
own set of supported application identifiers against all of the
application indentifier AVPs (Auth-Application-Id,
Acct-Application-Id and Vendor-Specific-Application-Id) present in
the CER. The value of the Vendor-Id AVP in the Vendor-Specific-
Application-Id MUST not be used during computation. The sender of
the Capabilities-Exchange-Answer (CEA) SHOULD include all of its
supported applications as a hint to the receiver regarding all of its
application capabilities.
Similarly, a receiver of a Capabilities-Exchange-Req (CER) message Similarly, a receiver of a Capabilities-Exchange-Req (CER) message
that does not have any security mechanisms in common with the sender that does not have any security mechanisms in common with the sender
MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code MUST return a Capabilities-Exchange-Answer (CEA) with the Result-Code
AVP set to DIAMETER_NO_COMMON_SECURITY, and SHOULD disconnect the AVP set to DIAMETER_NO_COMMON_SECURITY, and SHOULD disconnect the
transport layer connection. transport layer connection.
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 69, line 31 skipping to change at page 69, line 47
Host-IP- Address AVP for each address. This AVP MUST ONLY be used in Host-IP- Address AVP for each address. This AVP MUST ONLY be used in
the CER and CEA messages. the CER 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"
[RFC3232] value assigned to a vendor other than the device vendor. [RFC3232] value assigned to a vendor other than the device vendor.
This is used in the CER and CEA messages in order to inform the peer This is used in the CER and CEA messages in order to inform the peer
that the sender supports (a subset of) the vendor-specific AVPs that the sender supports (a subset of) the vendor-specific AVPs
defined by the vendor identified in this AVP. defined by the vendor identified in this AVP. The value of this AVP
SHOULD NOT be set to zero. Multiple instances of this AVP containing
the same value SHOULD NOT be sent.
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 70, line 14 skipping to change at page 70, line 35
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 been forwarded, and are likely in flight, messages have recently been forwarded, and are likely in flight,
which would otherwise cause a race condition. which 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. The sender of the Disconnect-Peer-Answer should be able
to detect the transport closure and cleanup the connection.
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
to 282 and the Command Flags' 'R' bit set, is sent to a peer to to 282 and the Command Flags' 'R' bit set, is sent to a peer to
inform its intentions to shutdown the transport connection. Upon inform its intentions to shutdown the transport connection. Upon
detection of a transport failure, this message MUST NOT be sent to an detection of a transport failure, this message MUST NOT be sent to an
alternate peer. alternate peer.
Message Format Message Format
skipping to change at page 79, line 8 skipping to change at page 79, line 8
Process-DWR The DWR message is serviced. Process-DWR The DWR message is serviced.
Process-DWA The DWA message is serviced. Process-DWA The DWA message is serviced.
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 with its own Origin-Host as two
Origin-Host. If the local Diameter entity's Origin-Host is higher streams of octets. If the local Origin-Host lexicographically
than the peer's, a Win-Election event is issued locally. succeeds the received Origin-Host a Win-Election event is issued
locally.
The comparison proceeds by considering the shorter OctetString to be To be consistent with DNS case insensitivity, octets that fall in the
padded with zeros so that it length is the same as the length of the ASCII range 'a' through 'z' MUST compare equally to their upper-case
longer, then performing an octet-by-octet unsigned comparison with counterparts between 'A' and 'Z', i.e. value 0x41 compares equal to
the first octet being most significant. Any remaining octets are 0x61, 0x42 to 0x62 and so forth up to and including 0x5a and 0x7a.
assumed to have value 0x80.
5.6.5. Capabilities Update 5.6.5. Capabilities Update
A Diameter node MUST initiate peer capabilities update by sending a A Diameter node MUST initiate peer capabilities update by sending a
Capabilities-Exchange-Req (CER) to all its peers which supports peer Capabilities-Exchange-Req (CER) to all its peers which supports peer
capabilities update and is in OPEN state. The receiver of CER in capabilities update and is in OPEN state. The receiver of CER in
open state MUST process and reply to the CER as a described in open state MUST process and reply to the CER as a described in
Section 5.3. The CEA which the receiver sends MUST contain its Section 5.3. The CEA which the receiver sends MUST contain its
latest capabilities. Note that peers which successfully process the latest capabilities. Note that peers which successfully process the
peer capabilities update SHOULD also update their routing tables to peer capabilities update SHOULD also update their routing tables to
skipping to change at page 83, line 28 skipping to change at page 83, line 28
Application-Id or Vendor-Specific-Application-Id instead of the Application-Id or Vendor-Specific-Application-Id instead of the
application id in the message header as a secondary measure. The application id in the message header as a secondary measure. The
realm MAY be retrieved from the User-Name AVP, which is in the form realm MAY be retrieved from the User-Name AVP, which is in the form
of a Network Access Identifier (NAI). The realm portion of the NAI of a Network Access Identifier (NAI). The realm portion of the NAI
is inserted in the Destination-Realm AVP. is inserted in the Destination-Realm AVP.
Diameter agents MAY have a list of locally supported realms and Diameter agents MAY have a list of locally supported realms and
applications, and MAY have a list of externally supported realms and applications, and MAY have a list of externally supported realms and
applications. When a request is received that includes a realm applications. When a request is received that includes a realm
and/or application that is not locally supported, the message is and/or application that is not locally supported, the message is
routed to the peer configured in the Realm Routing Table (see Section routed to the peer configured in the Routing Table (see Section 2.7).
2.7).
Realm names and application identifiers are the minimum supported
routing criteria, additional routing information maybe needed to
support redirect semantics.
6.1.7. Predictive Loop Avoidance 6.1.7. Predictive Loop Avoidance
Before forwarding or routing a request, Diameter agents, in addition Before forwarding or routing a request, Diameter agents, in addition
to processing done in Section 6.1.3, SHOULD check for the presence of to processing done in Section 6.1.3, SHOULD check for the presence of
candidate route's peer identity in any of the Route-Record AVPs. In candidate route's peer identity in any of the Route-Record AVPs. In
an event of the agent detecting the presence of a candidate route's an event of the agent detecting the presence of a candidate route's
peer identity in a Route-Record AVP, the agent MUST ignore such route peer identity in a Route-Record AVP, the agent MUST ignore such route
for the Diameter request message and attempt alternate routes if any. for the Diameter request message and attempt alternate routes if any.
In case all the candidate routes are eliminated by the above In case all the candidate routes are eliminated by the above
skipping to change at page 84, line 51 skipping to change at page 84, line 51
which includes the IP address, port and protocol. which includes the IP address, port and protocol.
A relay or proxy agent MAY include the Proxy-Info AVP in requests if A relay or proxy agent MAY include the Proxy-Info AVP in requests if
it requires access to any local state information when the it requires access to any local state information when the
corresponding response is received. Proxy-Info AVP has certain corresponding response is received. Proxy-Info AVP has certain
security implications and SHOULD contain an embedded HMAC with a security implications and SHOULD contain an embedded HMAC with a
node-local key. Alternatively, it MAY simply use local storage to node-local key. Alternatively, it MAY simply use local storage to
store state information. store state information.
The message is then forwarded to the next hop, as identified in the The message is then forwarded to the next hop, as identified in the
Realm Routing Table. Routing Table.
Figure 6 provides an example of message routing using the procedures Figure 6 provides an example of message routing using the procedures
listed in these sections. listed in these sections.
(Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net) (Origin-Host=nas.mno.net)
(Origin-Realm=mno.net) (Origin-Realm=mno.net) (Origin-Realm=mno.net) (Origin-Realm=mno.net)
(Destination-Realm=example.com) (Destination- (Destination-Realm=example.com) (Destination-
Realm=example.com) Realm=example.com)
(Route-Record=nas.example.net) (Route-Record=nas.example.net)
+------+ ------> +------+ ------> +------+ +------+ ------> +------+ ------> +------+
| | (Request) | | (Request) | | | | (Request) | | (Request) | |
| NAS +-------------------+ DRL +-------------------+ HMS | | NAS +-------------------+ DRL +-------------------+ HMS |
| | | | | | | | | | | |
+------+ <------ +------+ <------ +------+ +------+ <------ +------+ <------ +------+
example.net (Answer) example.net (Answer) example.com example.net (Answer) example.net (Answer) example.com
(Origin-Host=hms.example.com) (Origin-Host=hms.example.com) (Origin-Host=hms.example.com) (Origin-Host=hms.example.com)
(Origin-Realm=example.com) (Origin-Realm=example.com) (Origin-Realm=example.com) (Origin-Realm=example.com)
Figure 6: Routing of Diameter messages Figure 6: Routing of Diameter messages
Relay agents does not require full validation of incoming messages.
At the minimum, validation of the message header and relevant routing
AVPs has to be done when relaying messages.
6.2. Diameter Answer Processing 6.2. Diameter Answer Processing
When a request is locally processed, the following procedures MUST be When a request is locally processed, the following procedures MUST be
applied to create the associated answer, in addition to any applied to create the associated answer, in addition to any
additional procedures that MAY be discussed in the Diameter additional procedures that MAY be discussed in the Diameter
application defining the command: application defining the command:
o The same Hop-by-Hop identifier in the request is used in the o The same Hop-by-Hop identifier in the request is used in the
answer. answer.
skipping to change at page 100, line 6 skipping to change at page 100, line 6
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 of AVP MUST be included and contain a copy of the first instance of
the offending AVP that exceeded the maximum number of occurrences the offending AVP that exceeded the maximum number of occurrences
DIAMETER_NO_COMMON_APPLICATION 5010 DIAMETER_NO_COMMON_APPLICATION 5010
This error is returned when a CER message is received, and there This error is returned when a node that is not acting as a relay
are no common applications supported between the peers. and supporting a specific set of application has an empty
intersection with the set of application advertised by its peer.
DIAMETER_UNSUPPORTED_VERSION 5011 DIAMETER_UNSUPPORTED_VERSION 5011
This error is returned when a request was received, whose version This error is returned when a request was received, whose version
number is unsupported. number is unsupported.
DIAMETER_UNABLE_TO_COMPLY 5012 DIAMETER_UNABLE_TO_COMPLY 5012
This error is returned when a request is rejected for unspecified This error is returned when a request is rejected for unspecified
reasons. reasons.
skipping to change at page 132, line 26 skipping to change at page 132, line 26
Accounting-Realtime-Required AVP received earlier for the session in Accounting-Realtime-Required AVP received earlier for the session in
question. question.
Each Diameter Accounting protocol message MAY be compressed, in order Each Diameter Accounting protocol message MAY be compressed, in order
to reduce network bandwidth usage. If IPsec and IKE are used to to reduce network bandwidth usage. If IPsec and IKE are used to
secure the Diameter session, then IP compression [RFC3173] MAY be secure the Diameter session, then IP compression [RFC3173] MAY be
used and IKE [RFC2409] MAY be used to negotiate the compression used and IKE [RFC2409] MAY be used to negotiate the compression
parameters. If TLS is used to secure the Diameter session, then TLS parameters. If TLS is used to secure the Diameter session, then TLS
compression [RFC2246] MAY be used. compression [RFC2246] MAY be used.
9.3. Application document requirements 9.3. Accounting Application Extension and 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 message in a section entitled "Accounting AVPs". The application
MUST assume that the AVPs described in this document will be present MUST assume that the AVPs described in this document will be present
in all Accounting messages, so only their respective service-specific in 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.
Applications have the option of using one or both of the following
accounting application extension models:
Coupled Accounting Service
The accounting messages will carry the application identifier of
the application that is using it. The application itself will
process the received accounting records or forward them to an
accounting server. There is no accounting application
advertisement required during capabilities exchange and the
accounting messages will be routed the same as any of the other
application messages.
Split Accounting Service
The accounting message will carry the application identifier of
the Diameter base accounting application (see Section 2.4).
Accounting messages maybe routed to Diameter nodes other than the
corresponding Diameter application. These nodes might be
centralized accounting servers that provide accounting service for
multiple different Diameter applications. These nodes MUST
advertise the Diameter base accounting application identifier
during capabilities exchange.
Accounting messages which uses the Diameter base accounting
application identifier in its header MUST include the application
identifier of the Diameter application it is providing service for
in the Acct-Application-Id AVP. This allows the accounting server
to determine which Diameter application the accounting records are
for.
9.4. Fault Resilience 9.4. Fault Resilience
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
skipping to change at page 150, line 18 skipping to change at page 150, line 18
throughout this document: throughout this document:
Diameter Peer Diameter Peer
A Diameter entity MAY communicate with peers that are statically A Diameter entity MAY communicate with peers that are statically
configured. A statically configured Diameter peer would require configured. A statically configured Diameter peer would require
that either the IP address or the fully qualified domain name that either the IP address or the fully qualified domain name
(FQDN) be supplied, which would then be used to resolve through (FQDN) be supplied, which would then be used to resolve through
DNS. DNS.
Realm Routing Table Routing Table
A Diameter proxy server routes messages based on the realm portion A Diameter proxy server routes messages based on the realm portion
of a Network Access Identifier (NAI). The server MUST have a of a Network Access Identifier (NAI). The server MUST have a
table of Realm Names, and the address of the peer to which the table of Realm Names, and the address of the peer to which the
message must be forwarded to. The routing table MAY also include message must be forwarded to. The routing table MAY also include
a "default route", which is typically used for all messages that a "default route", which is typically used for all messages that
cannot be locally processed. cannot be locally processed.
Tc timer Tc timer
 End of changes. 31 change blocks. 
56 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/