Mercurial > hg > fD-testbed
comparison conf/opendiam.eap.testbed.aaa/opendiameter/diameter/configuration.xml @ 0:9e5a3c884de6
Initial import of the virtual testbed.
author | Sebastien Decugis <sdecugis@nict.go.jp> |
---|---|
date | Thu, 17 Jun 2010 11:00:32 +0900 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:9e5a3c884de6 |
---|---|
1 <?xml version="1.0" encoding="UTF-8"?> | |
2 <!DOCTYPE configuration SYSTEM "configuration.dtd"> | |
3 | |
4 <!-- Sample configuration file, version 1.0.3 and above. --> | |
5 <!-- Configuration table starts always starts with "configuration" | |
6 element as root --> | |
7 | |
8 <configuration> | |
9 | |
10 <!-- General configuration has a fixed list of elements. Note | |
11 that information in the general section includes to info | |
12 announced by this nodes to it's peers during capabilities | |
13 exchange. --> | |
14 <general> | |
15 | |
16 <!-- Product, version and vendor ID information specified | |
17 here will be embedded in the CER message --> | |
18 <product>Open Diameter</product> | |
19 | |
20 <!-- Software revision number. For Open Diameter | |
21 this is equivalent to the Firmware-Revision AVP | |
22 in the CER --> | |
23 <version>1</version> | |
24 | |
25 <!-- Vendor id of diameter entity broadcast to | |
26 peers in the CER --> | |
27 <vendor_id>0</vendor_id> | |
28 | |
29 <!-- List of locally supported vendor id's. Note | |
30 that advertisement of supported vendor id's | |
31 is needed when routing messages with vendor | |
32 specific application id's --> | |
33 <supported_vendor_id>0</supported_vendor_id> | |
34 <supported_vendor_id>1</supported_vendor_id> | |
35 | |
36 <!-- List of locally supported auth application | |
37 id's. This contains one or more auth application | |
38 id's that will be broadcasted to peers. To | |
39 advertise this node as a relay, place a '-1' | |
40 in either auth_application_id or acct_application_id --> | |
41 <auth_application_id>1</auth_application_id> | |
42 <auth_application_id>2</auth_application_id> | |
43 | |
44 <!-- List of locally supported acct application | |
45 id's. This contains one or more auth application | |
46 id's that will be broadcasted to peers. To | |
47 advertise this node as a relay, place a '-1' | |
48 in either auth_application_id or acct_application_id --> | |
49 <acct_application_id>3</acct_application_id> | |
50 <acct_application_id>4</acct_application_id> | |
51 | |
52 <!-- List of locally supported vendor specific application | |
53 id's. This contains one or more vendor specific application | |
54 id's that will be broadcasted to peers. Each vendor | |
55 specifc application id will contain one or more vendor | |
56 id's (RFC 3588) and exactly one auth or acct application | |
57 id --> | |
58 <vendor_specific_application_id> | |
59 | |
60 <!-- Exactly one instance of the vendor id is advertized | |
61 by this diameter entity --> | |
62 <vendor_id>31</vendor_id> | |
63 | |
64 <!-- Exactly one instance of the | |
65 vendor's auth application id --> | |
66 <auth_application_id>1</auth_application_id> | |
67 </vendor_specific_application_id> | |
68 <vendor_specific_application_id> | |
69 <vendor_id>41</vendor_id> | |
70 <!-- Or Exactly one instance of the | |
71 vendor's acct application id --> | |
72 <acct_application_id>6</acct_application_id> | |
73 </vendor_specific_application_id> | |
74 </general> | |
75 | |
76 <parser> | |
77 <!-- Path and filename of dictionary file. The path MUST be | |
78 a full path or relative to the location of this configuration | |
79 file --> | |
80 <dictionary>config\dictionary.xml</dictionary> | |
81 </parser> | |
82 | |
83 <!-- Transport management section. This section contains | |
84 to local diameter transport information, peer table | |
85 and route table --> | |
86 <transport_mngt> | |
87 | |
88 <!-- Diameter entity identity. Note that a running open | |
89 diameter application will use the identity string | |
90 instead of calling OS dependent gethostname functions | |
91 to determine it's identity. Hence, users MUST enter | |
92 a valid resovable entry for this string --> | |
93 <identity>nas_server</identity> | |
94 | |
95 <!-- Diameter realm. As with identity, a running open | |
96 diameter application uses the realm string to | |
97 identify its domain of reponsibility. This allows | |
98 virtual domains to exists within a single host | |
99 where multiple open diameter entities are running | |
100 with different realm configuration --> | |
101 <realm>research.org</realm> | |
102 | |
103 <!-- Diameter TCP listening port. Port number to listen | |
104 to for peer connection request. When using virtual | |
105 domains, make sure each entity listens to different | |
106 port numbers --> | |
107 <tcp_listen_port>1812</tcp_listen_port> | |
108 | |
109 <!-- Diameter SCTP listening port. Port number to listen | |
110 to for peer connection request. When using virtual | |
111 domains, make sure each entity listens to different | |
112 port numbers --> | |
113 <sctp_listen_port>1813</sctp_listen_port> | |
114 | |
115 <!-- Enables or disables IPv6 support for this stack --> | |
116 <use_ipv6>0</use_ipv6> | |
117 | |
118 <!-- Watchdog timeout. Interval between watchdog messages | |
119 --> | |
120 <watchdog_timeout>0</watchdog_timeout> | |
121 | |
122 <!-- Retry connection interval. Amount of time in between | |
123 attempts to reconnect to a disconnected peer. If the | |
124 value is 0, then no retry attempt will be made. | |
125 --> | |
126 <reconnect_interval>30</reconnect_interval> | |
127 | |
128 <!-- Max re-connection attempt. Number of times a reconnection | |
129 attempt will be made until it gives up. If the | |
130 value is 0, then no retry attempt will be made. | |
131 --> | |
132 <reconnect_max>30</reconnect_max> | |
133 | |
134 <!-- Request retransmission interval. Retransmission of | |
135 pending request will be done until max_request_retransmission | |
136 is exceeded. Care should be taken in defining this | |
137 value. A high value (>60) will slow down retransmission, | |
138 a low value (<5) will cause performance issues. If the | |
139 value is 0, then no retransmission attempt will be made. | |
140 --> | |
141 <request_retransmission_interval>10</request_retransmission_interval> | |
142 | |
143 <!-- Max request retransmission. Maximum number of pending | |
144 request retransmission. Care should be taken in defining this | |
145 value. A high value (>10) will cause too much traffic. | |
146 If the value is 0, then no retransmission attempt will be made. | |
147 --> | |
148 <max_request_retransmission_count>3</max_request_retransmission_count> | |
149 | |
150 <!-- This is the initial amount of buffer that is pre-allocated for | |
151 message reception. Each time a message is received that does | |
152 not fit this value, the buffer will be enlarged by this value | |
153 multiplied by increments of 1 until the message fits or up to | |
154 a maximum of 10 increments. A default vaule of 2048 is recommended. | |
155 --> | |
156 <receive_buffer_size>2048</receive_buffer_size> | |
157 | |
158 <!-- Provides a customized list of local hostnames | |
159 addresses that will be advertised to other | |
160 peers during CER/CEA exchange. For SCTP, | |
161 the IP addresses MUST be valid addresses | |
162 for all interface address present in the | |
163 system. For TCP, only the first IP address | |
164 will be used. | |
165 --> | |
166 <advertised_hostname>192.168.1.100</advertised_hostname> | |
167 <advertised_hostname>192.168.1.101</advertised_hostname> | |
168 <advertised_hostname>192.168.1.102</advertised_hostname> | |
169 | |
170 <!-- Peer table lists peers that this open diameter | |
171 application will attempt to connect to on startup. | |
172 Each peer entry contains host, port and tls | |
173 enabled information. Internally, the peer table | |
174 are currently configure statically using this section. | |
175 No dynamic learning is currently available --> | |
176 <peer_table> | |
177 <!-- This defines the expiration time for dynamically | |
178 learned peers --> | |
179 <expiration_time>1</expiration_time> | |
180 <peer> | |
181 <hostname>tari-dhcp163.research.telcordia.com</hostname> | |
182 <port>1812</port> | |
183 <!-- This flag indicates whether this connection will | |
184 be an SCTP connection. If set to 1, SCTP will be | |
185 used. If set to 0, TCP will be used --> | |
186 <use_sctp>1</use_sctp> | |
187 <tls_enabled>0</tls_enabled> | |
188 </peer> | |
189 </peer_table> | |
190 | |
191 <!-- Route table list the realm entries that this peer | |
192 will use to resolve message paths. Each entry | |
193 contains the realm name, the peer to send the | |
194 messaage to, the application id of the peer and | |
195 it role (whether a proxy, local .. etc). Note that | |
196 peer_reference element MUST point to an existing | |
197 peer in the peer_table else this route will be | |
198 in-active. Also, a default_route flag can be added | |
199 to a route entry to set the default route. If more | |
200 than one route has a default_route flag set then | |
201 the last entry with this flag set becomes the | |
202 default route --> | |
203 <route_table> | |
204 <!-- Defines the expiration time for dynamically | |
205 learned routes. A value of 0 means no expiration --> | |
206 <expire_time>0</expire_time> | |
207 | |
208 <!-- A route entry defines a lookup information | |
209 for a diameter message containing destination | |
210 realm AVP's. For more information on diameter | |
211 routing, pls see "Open Diameter Routing Architecture" --> | |
212 <route> | |
213 <!-- Realm that this route serves. MUST be unique to | |
214 this table --> | |
215 <realm>other.research.org</realm> | |
216 | |
217 <!-- The role that this diameter entity will play in | |
218 resolving messages matching this realm. Valid | |
219 values for this elements are: | |
220 0 (local) - application acting as local servers | |
221 1 (relay) - application acting as relay agent | |
222 2 (proxy) - application acting as proxy server | |
223 3 (redirect) - application acting as redirect agent --> | |
224 <role>0</role> | |
225 | |
226 <!-- Re-direct host usage. This provides a hint to | |
227 the receiver of the redirect indication on what | |
228 to do with the request. If this route is acting | |
229 as a redirect agent, the Redirect-Host-Usage AVP | |
230 sent in the redirect indication will have this value. | |
231 Note that this is valid only if <role> is set to | |
232 redirect(3). Valid values are: | |
233 0 DONT_CACHE - redirect host should not be cached. | |
234 1 ALL_SESSION - All messages within the same session id | |
235 MAY be sent to the redirect host | |
236 2 ALL_REALM - All messages destined for the realm | |
237 MAY be sent to the redirect host | |
238 3 REALM_AND_APPLICATION - All messages for the application | |
239 requested to the realm specified MAY be | |
240 sent to the redirect host | |
241 4 ALL_APPLICATION - All messages for the application | |
242 requested MAY be sent to the redirect host | |
243 5 ALL_HOST - All messages that would be sent to the | |
244 host that generated the Redirect-Host | |
245 MAY be sent to the redirect host | |
246 6 ALL_USER - All messages for the user requested MAY | |
247 be sent to the redirect host --> | |
248 <redirect_usage>0</redirect_usage> | |
249 | |
250 <!-- For each route, there is a set of applications | |
251 that are supported. This is used by the base | |
252 protocol library as the second index to resolving | |
253 a route for a message --> | |
254 <application> | |
255 | |
256 <!-- Application Id is used as a second key for | |
257 routing queries. See details above --> | |
258 <application_id>1</application_id> | |
259 | |
260 <!-- For vendor specific application id's. As | |
261 per RFC this should be 0 for standard | |
262 track applications. Otherwise, this | |
263 value is used in conjunction with | |
264 application_id as a second search key --> | |
265 <vendor_id>0</vendor_id> | |
266 | |
267 <!-- For each application, there can be a set | |
268 of servers support it. Each server has | |
269 a metric associated with it and the | |
270 routing engine chooses the server in | |
271 metric order (0 being highest) --> | |
272 <peer_entry> | |
273 | |
274 <!-- Diameter peer serving this realm and | |
275 application id. This server name | |
276 MUST exits in the peer table for | |
277 this route to be active. | |
278 <server>server1.research.org</server> | |
279 | |
280 <!-- Metric value for this server entry. | |
281 The higher the value, the lower the | |
282 preference. 0 is the highest value | |
283 and entries with equal value will | |
284 be resolve in the order they are | |
285 defined in this configuration file --> | |
286 <metric>1</metric> | |
287 </peer_entry> | |
288 <peer_entry> | |
289 <server>server2.research.org</server> | |
290 <metric>5</metric> | |
291 </peer_entry> | |
292 </application> | |
293 <application> | |
294 <application_id> | |
295 <id>1</id> | |
296 <type>1</type> | |
297 </application_id> | |
298 <peer_entry> | |
299 <server>server1.research.org</server> | |
300 <metric>1</metric> | |
301 </peer_entry> | |
302 <peer_entry> | |
303 <server>server6.research.org</server> | |
304 <metric>5</metric> | |
305 </peer_entry> | |
306 </application> | |
307 </route> | |
308 | |
309 <!-- The definition of a default route is the same | |
310 as for any other route. The existance of a | |
311 default route means that all no-match queries | |
312 will result in a default route return --> | |
313 <default_route> | |
314 <realm>research.telcordia.com</realm> | |
315 <role>full</role> | |
316 <application> | |
317 <application_id> | |
318 <id>1</id> | |
319 <type>1</type> | |
320 </application_id> | |
321 <peer_entry> | |
322 <server>server1.research.org</server> | |
323 <metric>1</metric> | |
324 </peer_entry> | |
325 <peer_entry> | |
326 <server>server2.research.org</server> | |
327 <metric>5</metric> | |
328 </peer_entry> | |
329 </application> | |
330 <application> | |
331 <application_id> | |
332 <id>5</id> | |
333 <type>1</type> | |
334 </application_id> | |
335 <peer_entry> | |
336 <server>server1.research.org</server> | |
337 <metric>1</metric> | |
338 </peer_entry> | |
339 <peer_entry> | |
340 <server>server6.research.org</server> | |
341 <metric>5</metric> | |
342 </peer_entry> | |
343 </application> | |
344 </route> | |
345 </route_table> | |
346 </transport_mngt> | |
347 | |
348 <!-- Session manager configuration table. This section | |
349 consist of fixed elements that MUST exists --> | |
350 <session_mngt> | |
351 | |
352 <!-- Dictates the maximum number of concurrent | |
353 sessions that will be maintained by open | |
354 diameter. These include both auth and acct | |
355 sessions --> | |
356 <max_sessions>10000</max_sessions> | |
357 | |
358 <!-- The following dictates default values for | |
359 auth sessions --> | |
360 <auth_sessions> | |
361 | |
362 <!-- Stateful session flag. If set to 1, then | |
363 server will enforce stateful sessions and | |
364 clients will hint for stateful sessions. If | |
365 set to 0 or if missing then stateless sessions. | |
366 | |
367 The value of auth-session state can actually | |
368 negotiated between client and server. So for | |
369 the server, auth-session-state is used as follows: | |
370 | |
371 1. If the request message sent by the client | |
372 contains an auth-session-state, the server | |
373 check's it's own configuration. If the values | |
374 are equal then the server uses that value to | |
375 determine statefulness. If the values are not | |
376 equal and the server's configuration is set to | |
377 AAA_SESSION_STATE_MAINTAINED, then the client's | |
378 value determines the statefulness of the session. | |
379 If the values are not equal and the server's | |
380 configuration is NOT AAA_SESSION_STATE_MAINTAINED | |
381 then the server's configuration determines the | |
382 statefulness. | |
383 2. If the request message sent by the client does | |
384 not contain an auth-session-state, the server | |
385 check's the settings of SetAuthSessionState() | |
386 function. If SetAuthSessionState() returns a | |
387 value, it is used to determine the statefulness | |
388 of the session otherwise the configuration value | |
389 is used. | |
390 | |
391 Based on the above policy, the server will return | |
392 an auth-session-state avp in answer message. | |
393 | |
394 For the client: | |
395 | |
396 1. The initial request sent by the client can contain | |
397 an auth-session-state value as a hint to the server. | |
398 This value is taken from the settings of SetAuthSessionState() | |
399 function. If SetAuthSessionState() returns a value, | |
400 it is used to as a hint value otherwise the configuration | |
401 value is used. | |
402 2. If the answer message sent by the server contains | |
403 an auth-session-state, then that value will be used | |
404 by the client. If no auth-session-state avp is sent, | |
405 then the hint sent in (1) is used. | |
406 --> | |
407 <stateful>1</stateful> | |
408 | |
409 <!-- Timeout in seconds before a session requires | |
410 re-authentication. For stateless sessions, a value | |
411 of zero(0) will cause the client session to be maintained | |
412 indefinitely. For stateless server sessions, the library | |
413 will ask you periodically if you want to reclaim the session | |
414 in ReClaimSession() method --> | |
415 <session_timeout>30</session_timeout> | |
416 | |
417 <!-- Timeout in seconds before a session is | |
418 terminated regardless of wether it has | |
419 been re-authenticated --> | |
420 <lifetime_timeout>360</lifetime_timeout> | |
421 | |
422 <!-- Grace period after lifetime timeout before | |
423 full termination --> | |
424 <grace_period_timeout>30</grace_period_timeout> | |
425 | |
426 <!-- Timeout before subsequent ASR messages | |
427 are sent if the inital attempt fails --> | |
428 <abort_retry_timeout>20</abort_retry_timeout> | |
429 | |
430 </auth_sessions> | |
431 | |
432 <!-- The following dictates default values for | |
433 acct sessions --> | |
434 <acct_sessions> | |
435 | |
436 <!-- Timeout in seconds before a session requires | |
437 re-authentication --> | |
438 <session_timeout>30</session_timeout> | |
439 | |
440 <!-- Record interim interval dictated to the client | |
441 if this entity is a server or hint to the server | |
442 if this is a client --> | |
443 <interim_interval>5</interim_interval> | |
444 | |
445 <!-- Realtime required value dictated to the client | |
446 if this entity is a server or hint to the server | |
447 if this is a client --> | |
448 <realtime>1</realtime> | |
449 | |
450 </acct_sessions> | |
451 | |
452 </session_mngt> | |
453 | |
454 <!-- Log section dictates the verbose levels that | |
455 the library generates as well as target outputs --> | |
456 <log> | |
457 | |
458 <!-- The following are the available log levels | |
459 that can be "enabled" or "disabled" --> | |
460 <flags> | |
461 <debug>disabled</debug> | |
462 <trace>disabled</trace> | |
463 <info>disabled</info> | |
464 </flags> | |
465 | |
466 <!-- The following are the target outputs of | |
467 the logs. It can be a combination of | |
468 each entry --> | |
469 <target> | |
470 <!-- enables or disables terminal output --> | |
471 <console>enabled</console> | |
472 <!-- enables or disables syslog output --> | |
473 <syslog>disabled</syslog> | |
474 </target> | |
475 </log> | |
476 </configuration> |