Peer Discovery

Before Diameter, system administrators had to manually configure the Network Access Server with the location of its AAA server, so that when a user came in, the device could send a request to the correct address. Such configuration efforts could, however, be tedious for a complex network deployment. One notable enhancement in Diameter is its peer discovery capability. Besides manual configuration, which must be supported by all Diameter nodes, two options -- SRVLOC and DNS -- may be supported for dynamic peer discovery. The concept here is that it is required for Diameter server, or Diameter agent, to broadcast which applications they support, along with the provided security level. Diameter clients can then depend on the desired Diameter application, security level, and realm info to look up suitable first-hop Diameter nodes to which they can forward Diameter messages. For a Diameter node, the discovered peer location as well as routing configuration will be stored locally using two Diameter tables:

Peer Table.

A Peer Table is mainly used to store the host address of known Diameter nodes. Other information, like whether a Diameter node was looked up dynamically, its status, and security-related information of that node, is also included in this table.

Peer Routing Table.

There are four important columns of this table requiring extra attention for message routing. The first two are the Realm Name and Application Name, which act as the selection criteria for message routing. The third is the action to be taken for the target message, which could be PROXY, RELAY, REDIRECT, or LOCAL. LOCAL means the message should be processed locally instead of forwarding to other nodes. The last one is a reference to an entry in the Peer Table, used to determine the actual host address of the destination. Note that a Peer Routing Table will always contain a default entry for messages not meeting the routing criteria.

Connection and session

After an appropriate peer has been discovered, the next step is to establish a connection with that peer. A connection is a physical link between two Diameter nodes. It is mandatory for the Diameter protocol to run over either TCP or SCTP. Compared with UDP, used in RADIUS, these two protocols provide more reliable transportation, which is critical for applications exchanging accounting-related information. Given that Diameter is basically a peer-to-peer architecture; there could be more than one connection established for a particular node. Diameter protocol explicitly defines that a Diameter node must establish a connection with two peers per realm at a minimum, which act as primary and secondary contacts. Of course, additional connections could be established when necessary. Compared with a connection, a session is a logical connection between two Diameter nodes, and can cross multiple connections. A session is actually the concept of a sequence of activities within a timeframe, and refers to the interactions between a Diameter client and a Diameter server in a given period. Each session in Diameter is associated with a client-generated Session-Id that is globally and eternally unique. The Session-Id is then used to identify a particular session during further communication. Figure 6 shows the concept of a connection and session: