Mercurial > hg > fD-testbed
comparison conf/opendiam.eap.testbed.aaa/opendiameter/diameternasreq/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. --> | |
| 39 <auth_application_id>1</auth_application_id> | |
| 40 <auth_application_id>2</auth_application_id> | |
| 41 | |
| 42 <!-- List of locally supported acct application | |
| 43 id's. This contains one or more auth application | |
| 44 id's that will be broadcasted to peers. --> | |
| 45 <acct_application_id>3</acct_application_id> | |
| 46 <acct_application_id>4</acct_application_id> | |
| 47 | |
| 48 <!-- List of locally supported vendor specific application | |
| 49 id's. This contains one or more vendor specific application | |
| 50 id's that will be broadcasted to peers. Each vendor | |
| 51 specifc application id will contain one or more vendor | |
| 52 id's (RFC 3588) and exactly one auth or acct application | |
| 53 id --> | |
| 54 <vendor_specific_application_id> | |
| 55 | |
| 56 <!-- List of vendor id's advertized by this diameter | |
| 57 entity --> | |
| 58 <vendor_id>31</vendor_id> | |
| 59 <vendor_id>32</vendor_id> | |
| 60 <vendor_id>33</vendor_id> | |
| 61 | |
| 62 <!-- Exactly one instance of the | |
| 63 vendor's auth application id --> | |
| 64 <auth_application_id>1</auth_application_id> | |
| 65 | |
| 66 <!-- Or Exactly one instance of the | |
| 67 vendor's acct application id --> | |
| 68 <acct_application_id>4</acct_application_id> | |
| 69 </vendor_specific_application_id> | |
| 70 <vendor_specific_application_id> | |
| 71 <vendor_id>41</vendor_id> | |
| 72 <vendor_id>42</vendor_id> | |
| 73 <vendor_id>43</vendor_id> | |
| 74 <auth_application_id>5</auth_application_id> | |
| 75 <acct_application_id>6</acct_application_id> | |
| 76 </vendor_specific_application_id> | |
| 77 </general> | |
| 78 | |
| 79 <parser> | |
| 80 <!-- Path and filename of dictionary file. The path MUST be | |
| 81 a full path or relative to the location of this configuration | |
| 82 file --> | |
| 83 <dictionary>config\dictionary.xml</dictionary> | |
| 84 </parser> | |
| 85 | |
| 86 <!-- Transport management section. This section contains | |
| 87 to local diameter transport information, peer table | |
| 88 and route table --> | |
| 89 <transport_mngt> | |
| 90 | |
| 91 <!-- Diameter entity identity. Note that a running open | |
| 92 diameter application will use the identity string | |
| 93 instead of calling OS dependent gethostname functions | |
| 94 to determine it's identity. Hence, users MUST enter | |
| 95 a valid resovable entry for this string --> | |
| 96 <identity>nas_server</identity> | |
| 97 | |
| 98 <!-- Diameter realm. As with identity, a running open | |
| 99 diameter application uses the realm string to | |
| 100 identify its domain of reponsibility. This allows | |
| 101 virtual domains to exists within a single host | |
| 102 where multiple open diameter entities are running | |
| 103 with different realm configuration --> | |
| 104 <realm>research.org</realm> | |
| 105 | |
| 106 <!-- Diameter TCP listening port. Port number to listen | |
| 107 to for peer connection request. When using virtual | |
| 108 domains, make sure each entity listens to different | |
| 109 port numbers --> | |
| 110 <tcp_listen_port>1812</tcp_listen_port> | |
| 111 | |
| 112 <!-- Diameter SCTP listening port. Port number to listen | |
| 113 to for peer connection request. When using virtual | |
| 114 domains, make sure each entity listens to different | |
| 115 port numbers --> | |
| 116 <sctp_listen_port>1813</sctp_listen_port> | |
| 117 | |
| 118 <!-- Enables or disables IPv6 support for this stack --> | |
| 119 <use_ipv6>0</use_ipv6> | |
| 120 | |
| 121 <!-- Watchdog timeout. Interval between watchdog messages | |
| 122 --> | |
| 123 <watchdog_timeout>0</watchdog_timeout> | |
| 124 | |
| 125 <!-- Retry connection interval. Amount of time in between | |
| 126 attempts to reconnect to a disconnected peer. If the | |
| 127 value is 0, then no retry attempt will be made. | |
| 128 --> | |
| 129 <reconnect_interval>30</reconnect_interval> | |
| 130 | |
| 131 <!-- Max re-connection attempt. Number of times a reconnection | |
| 132 attempt will be made until it gives up. If the | |
| 133 value is 0, then no retry attempt will be made. | |
| 134 --> | |
| 135 <reconnect_max>30</reconnect_max> | |
| 136 | |
| 137 <!-- Request retransmission interval. Retransmission of | |
| 138 pending request will be done until max_request_retransmission | |
| 139 is exceeded. Care should be taken in defining this | |
| 140 value. A high value (>60) will slow down retransmission, | |
| 141 a low value (<5) will cause performance issues. If the | |
| 142 value is 0, then no retransmission attempt will be made. | |
| 143 --> | |
| 144 <request_retransmission_interval>10</request_retransmission_interval> | |
| 145 | |
| 146 <!-- Max request retransmission. Maximum number of pending | |
| 147 request retransmission. Care should be taken in defining this | |
| 148 value. A high value (>10) will cause too much traffic. | |
| 149 If the value is 0, then no retransmission attempt will be made. | |
| 150 --> | |
| 151 <max_request_retransmission_count>3</max_request_retransmission_count> | |
| 152 | |
| 153 <!-- This is the initial amount of buffer that is pre-allocated for | |
| 154 message reception. Each time a message is received that does | |
| 155 not fit this value, the buffer will be enlarged by this value | |
| 156 multiplied by increments of 1 until the message fits or up to | |
| 157 a maximum of 10 increments. A default vaule of 2048 is recommended. | |
| 158 --> | |
| 159 <receive_buffer_size>2048</receive_buffer_size> | |
| 160 | |
| 161 <!-- Provides a customized list of local host IP | |
| 162 addresses that will be advertised to other | |
| 163 peers during CER/CEA exchange. For SCTP, | |
| 164 the IP addresses MUST be valid addresses | |
| 165 for all interface address present in the | |
| 166 system. For TCP, only the first IP address | |
| 167 will be used. | |
| 168 --> | |
| 169 <advertised_host_ip>192.168.1.100</advertised_host_ip> | |
| 170 <advertised_host_ip>192.168.1.101</advertised_host_ip> | |
| 171 <advertised_host_ip>192.168.1.102</advertised_host_ip> | |
| 172 | |
| 173 <!-- Peer table lists peers that this open diameter | |
| 174 application will attempt to connect to on startup. | |
| 175 Each peer entry contains host, port and tls | |
| 176 enabled information. Internally, the peer table | |
| 177 are currently configure statically using this section. | |
| 178 No dynamic learning is currently available --> | |
| 179 <peer_table> | |
| 180 <!-- This defines the expiration time for dynamically | |
| 181 learned peers --> | |
| 182 <expiration_time>1</expiration_time> | |
| 183 <peer> | |
| 184 <hostname>tari-dhcp163.research.telcordia.com</hostname> | |
| 185 <port>1812</port> | |
| 186 <use_sctp>0</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> |