configuration.xml.svn-base

在Diameter3588协议的基础上开发的软件

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration SYSTEM "configuration.dtd">

<!-- Sample configuration file, version 1.0.3 and above. -->
<!-- Configuration table starts always starts with "configuration"
     element as root -->

<configuration>

   <!-- General configuration has a fixed list of elements. Note
        that information in the general section includes to info 
        announced by this nodes to it's peers during capabilities
        exchange. -->
   <general>

      <!-- Product, version and vendor ID information specified
           here will be embedded in the CER message -->
      <product>Open Diameter</product>

      <!-- Software revision number. For Open Diameter
           this is equivalent to the Firmware-Revision AVP
           in the CER -->
      <version>1</version>

      <!-- Vendor id of diameter entity broadcast to 
           peers in the CER -->
      <vendor_id>0</vendor_id>

      <!-- List of locally supported vendor id's. Note
           that advertisement of supported vendor id's
           is needed when routing messages with vendor
           specific application id's -->
      <supported_vendor_id>0</supported_vendor_id>
      <supported_vendor_id>1</supported_vendor_id>

      <!-- List of locally supported auth application 
           id's. This contains one or more auth application
           id's that will be broadcasted to peers. -->
      <auth_application_id>1</auth_application_id>
      <auth_application_id>2</auth_application_id>

      <!-- List of locally supported acct application
           id's. This contains one or more auth application
           id's that will be broadcasted to peers. -->
      <acct_application_id>3</acct_application_id>
      <acct_application_id>4</acct_application_id>

      <!-- List of locally supported vendor specific application
           id's. This contains one or more vendor specific application
           id's that will be broadcasted to peers.  Each vendor
           specifc application id will contain one or more vendor
           id's (RFC 3588) and exactly one auth or acct application
           id -->
      <vendor_specific_application_id>

          <!-- List of vendor id's advertized by this diameter
               entity -->
          <vendor_id>31</vendor_id>
          <vendor_id>32</vendor_id>
          <vendor_id>33</vendor_id>

          <!-- Exactly one instance of the
               vendor's auth application id -->  
          <auth_application_id>1</auth_application_id>

          <!-- Or Exactly one instance of the
               vendor's acct application id -->  
          <acct_application_id>4</acct_application_id>
      </vendor_specific_application_id>
      <vendor_specific_application_id>
          <vendor_id>41</vendor_id>
          <vendor_id>42</vendor_id>
          <vendor_id>43</vendor_id>
          <auth_application_id>5</auth_application_id>
          <acct_application_id>6</acct_application_id>
      </vendor_specific_application_id>
   </general>

   <parser> 
      <!-- Path and filename of dictionary file. The path MUST be
           a full path or relative to the location of this configuration
           file -->
      <dictionary>config\dictionary.xml</dictionary>
   </parser>

   <!-- Transport management section. This section contains 
        to local diameter transport information, peer table
        and route table -->
   <transport_mngt>

      <!-- Diameter entity identity. Note that a running open
           diameter application will use the identity string 
           instead of calling OS dependent gethostname functions
           to determine it's identity. Hence, users MUST enter
           a valid resovable entry for this string -->
      <identity>nas_server</identity>

      <!-- Diameter realm. As with identity, a running open
           diameter application uses the realm string to
           identify its domain of reponsibility. This allows
           virtual domains to exists within a single host
           where multiple open diameter entities are running
           with different realm configuration --> 
      <realm>research.org</realm>

      <!-- Diameter TCP listening port. Port number to listen
           to for peer connection request. When using virtual
           domains, make sure each entity listens to different
           port numbers -->
      <tcp_listen_port>1812</tcp_listen_port>

      <!-- Diameter SCTP listening port. Port number to listen
           to for peer connection request. When using virtual
           domains, make sure each entity listens to different
           port numbers -->
      <sctp_listen_port>1813</sctp_listen_port>

      <!-- Enables or disables IPv6 support for this stack -->
      <use_ipv6>0</use_ipv6>

      <!-- Watchdog timeout. Interval between watchdog messages 
           -->
      <watchdog_timeout>0</watchdog_timeout>

      <!-- Retry connection interval. Amount of time in between
           attempts to reconnect to a disconnected peer. If the
           value is 0, then no retry attempt will be made.
           -->
      <reconnect_interval>30</reconnect_interval>

      <!-- Max re-connection attempt. Number of times a reconnection
           attempt will be made until it gives up. If the
           value is 0, then no retry attempt will be made.
           -->
      <reconnect_max>30</reconnect_max>

      <!-- Request retransmission interval. Retransmission of
           pending request will be done until max_request_retransmission
           is exceeded. Care should be taken in defining this
           value. A high value (>60) will slow down retransmission,
           a low value (<5) will cause performance issues. If the
           value is 0, then no retransmission attempt will be made.
           -->
      <request_retransmission_interval>10</request_retransmission_interval>

      <!-- Max request retransmission. Maximum number of pending
           request retransmission. Care should be taken in defining this
           value. A high value (>10) will cause too much traffic.
           If the value is 0, then no retransmission attempt will be made.
           -->
      <max_request_retransmission_count>3</max_request_retransmission_count>

      <!-- This is the initial amount of buffer that is pre-allocated for
           message reception. Each time a message is received that does
           not fit this value, the buffer will be enlarged by this value
           multiplied by increments of 1 until the message fits or up to
           a maximum of 10 increments. A default vaule of 2048 is recommended.
           -->
      <receive_buffer_size>2048</receive_buffer_size>

      <!-- Provides a customized list of local host IP 
           addresses that will be advertised to other
           peers during CER/CEA exchange. For SCTP, 
	   the IP addresses MUST be valid addresses
	   for all interface address present in the
	   system. For TCP, only the first IP address
	   will be used.
           -->
      <advertised_host_ip>192.168.1.100</advertised_host_ip>
      <advertised_host_ip>192.168.1.101</advertised_host_ip>
      <advertised_host_ip>192.168.1.102</advertised_host_ip>
      
      <!-- Peer table lists peers that this open diameter 
           application will attempt to connect to on startup.
           Each peer entry contains host, port and tls
           enabled information.  Internally, the peer table 
           are currently configure statically using this section. 
           No dynamic learning is currently available -->
      <peer_table>
          <!-- This defines the expiration time for dynamically
                learned peers -->
          <expiration_time>1</expiration_time>
          <peer>
              <hostname>tari-dhcp163.research.telcordia.com</hostname>
              <port>1812</port>
              <use_sctp>0</use_sctp>
              <tls_enabled>0</tls_enabled>
          </peer>
      </peer_table>

      <!-- Route table list the realm entries that this peer
           will use to resolve message paths. Each entry
           contains the realm name, the peer to send the
           messaage to, the application id of the peer and
           it role (whether a proxy, local .. etc). Note that
           peer_reference element MUST point to an existing
           peer in the peer_table else this route will be
           in-active. Also, a default_route flag can be added
           to a route entry to set the default route. If more
           than one route has a default_route flag set then
           the last entry with this flag set becomes the
           default route -->
      <route_table>
          <!-- Defines the expiration time for dynamically
               learned routes. A value of 0 means no expiration -->
          <expire_time>0</expire_time>

          <!-- A route entry defines a lookup information
               for a diameter message containing destination
               realm AVP's. For more information on diameter
               routing, pls see "Open Diameter Routing Architecture" -->
          <route>
             <!-- Realm that this route serves. MUST be unique to
                   this table --> 
             <realm>other.research.org</realm>

             <!-- The role that this diameter entity will play in
                  resolving messages matching this realm. Valid 
                  values for this elements are:
                   0 (local)    - application acting as local servers
                   1 (relay)    - application acting as relay agent                  
                   2 (proxy)    - application acting as proxy server
                   3 (redirect) - application acting as redirect agent -->
             <role>0</role> 

             <!-- Re-direct host usage. This provides a hint to
                  the receiver of the redirect indication on what
                  to do with the request. If this route is acting
                  as a redirect agent, the Redirect-Host-Usage AVP
                  sent in the redirect indication will have this value.
                  Note that this is valid only if <role> is set to
                  redirect(3). Valid values are:
                    0  DONT_CACHE  - redirect host should not be cached.
                    1  ALL_SESSION - All messages within the same session id
                                     MAY be sent to the redirect host
                    2  ALL_REALM   - All messages destined for the realm
                                     MAY be sent to the redirect host
                    3  REALM_AND_APPLICATION - All messages for the application
                                     requested to the realm specified MAY be