 Now let's look at the overall architecture of diameter and the nodes and the agents which are used to realize the communication between client and server and between peers themselves. The network architecture for diameter is based on certain entities which are known as peers which could be a client or a server or even agents. Let's start with the agents first. The most important agent that allows the communication between client and server to be realized is the relay agent. It roots messages from the client to the server and from one intermediate relay agent even to the other intermediate relay agent. In order to make sure that the diameter messages are actually successfully delivered between the client and the server, it uses routing information which comes in the received message. It is known as the destination real application value pair. Now this value pair is actually a tuple that contains information regarding the destination, regarding the source, regarding additional information that we've already covered. Now this relay agent is actually performing kind of routing activity. So it is at one point in time connected to multiple IP networks. So this means the scope of the diameter protocol spans multiple IP subnet. Since the relay agent is only going to relay the diameter messages, it is transparent or we can say it does not alter the diameter messages. However, it must advertise its own application ID because all the agents have to work with some compatible diameter version and protocol. So for that, the application ID in this case, for instance, if it is going to be all ones are transmitted to show that this particular variant of the application ID is available at the moment by relay agent. If it changes in that case, the application ID means that this relay agent is going to work specifically for a certain diameter protocol. The next agent is the proxy agent as we understand proxy is usually an entity that works on behalf of someone else. So in that case, it could be a proxy for the client or it could be a proxy for the server. Now the proxy also has to perform forwarding, which is quite similar to the relay agent. However, there is some difference. The proxy agent actually routes or forwards the messages through a mechanism known as the diameter routing table. Now this diameter routing table actually is the lookup table, which is consulted to compare the forwarding decision. The only difference which is here in proxy agents is that the proxy agent is now going to alter. It can alter the diameter message contents, so it means depending upon what is coming in, if it has to work on behalf of the client or the server, it can change the contents of the message like it can append its own ID. While doing so, it also maintains state of its downstream peers, that is, the messages which are coming from certain clients are requesting this proxy to work on their behalf, so it has to maintain a log of which clients are making its specific request. And then it also, similar to the relay agent, advertises its own version and its own ID because the policy needs to be enforced for a certain diameter protocol. Then we have the redirect agent. It is used where usually the routing information is not stored, is not available with the relay agent or with the proxy agent, rather it is stored on a central location. So in that case, every node, whether it's a redirect, it's a proxy agent or a relay agent will have to consult the redirect agent. So it means the redirect agent is not going to forward or relay the information to any peer or any agent, rather it is just going to reply and provide information with to whom the information has to be forwarded to. Like the relay agent and the proxy agent, the redirect agent also needs to advertise its own application ID. Then lastly we have the translation agent. As the name suggests, it translates the diameter messages to backward compatible for backward compatibility to radius messages and vice versa. So this makes sure that the earlier versions of AAA protocols and services are also applicable within one administrative domain. Let's finally look at the relationship between the client and server, which is realized through a series of agents. We have the diameter client, which has realm A, the server which has realm B, then we have the request which is being initiated from the client. You can see that it is numbered as one, two, three, four, five, six. However, these two are different. The one that we see here is once no redirection is involved, then it is simply from the client to the server via either a relay or the proxy agent. So you see here that from one realm to the other, the message is sent in a undirected or in a straight manner. But once redirection is required, in that case, the path or the route is now determined by the redirect agent. The redirect agent is not routing itself, but it is only providing information on to which agent, whether relay or proxy, the information has to be forwarded to. So in that case, you see that we have to follow the sequence of one, two, three, four, five and six. Now this is an interesting situation that you can always expect that what if a certain transport of diameter message fails. In that case, an alternate diameter peer that is another relay agent is utilized. However, since it is failover activity, in that case, the rerouting is done with a t-bit set that actually means that this particular message is now being delivered on an alternate path. So this keeps the network administrators fully aware of what is going on in their network.