1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
<?xml version="1.0" encoding="latin1" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">
<chapter>
<header>
<copyright>
<year>2011</year>
<holder>Ericsson AB. All Rights Reserved.</holder>
</copyright>
<legalnotice>
The contents of this file are subject to the Erlang Public License,
Version 1.1, (the "License"); you may not use this file except in
compliance with the License. You should have received a copy of the
Erlang Public License along with this software. If not, it can be
retrieved online at http://www.erlang.org/.
Software distributed under the License is distributed on an "AS IS"
basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
the License for the specific language governing rights and limitations
under the License.
</legalnotice>
<title>Introduction</title>
<prepared></prepared>
<responsible></responsible>
<docno></docno>
<approved></approved>
<checked></checked>
<date></date>
<rev></rev>
<file>diameter_intro.xml</file>
</header>
<p>
The diameter application is an implementation of the Diameter protocol
as defined by RFC 3588.
It supports arbitrary Diameter applications by way of a
<em>dictionary</em> interface that allows messages and AVP's to be
defined and input into diameter as configuration.
It has support for all roles defined in the RFC: client, server and
agent.
This chapter provides a short overview of the application.</p>
<p>
A Diameter peer is implemented by configuring a <em>service</em> and
one or more <em>transports</em> using the interface module
<seealso marker="diameter">diameter</seealso>.
The service configuration defines the Diameter applications to be
supported by the peer and, typically, the capabilities that it should
send to remote peers at capabilities exchange upon the establishment
of transport connections.
A transport is configured on a service and provides protocol-specific
send/receive functionality by way of a transport interface defined by
diameter and implemented by a transport module.
The diameter application provides two transport modules: <seealso
marker="diameter_tcp">diameter_tcp</seealso> and <seealso
marker="diameter_sctp">diameter_sctp</seealso> for transport over TCP
(using <c>gen_tcp</c>) and SCTP (using <c>gen_sctp</c>) respectively.
Other transports can be provided by any module that implements
diameter's <seealso marker="diameter_transport">transport
interface</seealso>.</p>
<p>
While a service typically implements a single Diameter peer (as
identified by an Origin-Host AVP), transports can themselves be
associated with capabilities AVP's so that a single service be used to
implement more than one Diameter peer.</p>
<p>
Each Diameter application defined on a service is configured with a
callback module that implements the <seealso
marker="diameter_app">application interface</seealso> through which
diameter communicates the connectivity of remote peers, requests peer
selection for outgoing requests, and communicates the reception of
incoming Diameter request and answer messages.
An application using diameter implements these application callback
modules to provide the functionality of the Diameter peer(s) it
implements.</p>
<p>
Each Diameter application is also configured with one or more
dictionary modules
that provide encode/decode functionality for outgoing/incoming
Diameter messages.
A module is generated from a <seealso
marker="diameter_dict">specification file</seealso> using the <seealso
marker="diameterc">diameterc</seealso> utility.
Dictionaries for the RFC 3588 Diameter Common Messages, Base
Accounting and Relay applications are provided by the diameter
application.</p>
</chapter>
|
