top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Diameter Peer and Realm

+2 votes
3,782 views

Probably is bigineer question. Diameter protocol maintains two table one is peer and other is realm. My question here is what is the requirement of having two tables here. We can have only one i.e. Peer Table which will tell us which peer to be reached. Looks that I am missing some part...

posted Jul 24, 2013 by Sumit Pokharna

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+2 votes
 
Best answer

Realm routing table is used in routing of requests. Each request will have destination realm and application id. A lookup is performed on the realm table to pick up the next-hop peer for this combination of dest realm+application id. This step won't be necessary if the request specifically has destination-host name also, but in general, requests won't have this optional AVP filled.
Even when destination-host is present, note that it need not be a known peer. A peer is a host we can connect to and reach, but a request may take multiple hops to reach final destination.

Peer table maintains information about all known peers. So in general, peer table will be used for connection management while realm table will be used for forwarding.

Implementations may merge them (though I don't see why they would do that).
rk

answer Jul 25, 2013 by Rathnakumar Kayyar
+1 vote

The Diameter client could be common to multiple enterprises/departments with different domain names such as 1.abc.com, 2.abc.com, xyz.com. In the case where each of these domains have different AAA servers, the NAS client will need to route the request to the appropriate domain based on the NAI(in the format user@domain.com) received from the user.
Therefore the client needs to maintain a peer table (as configured).
The realm table will be required to map the target domain to the AAA servers, to help the client entity route the request based on the received NAI. Most NAS clients support NAS server grouping for redundancy/loadbalancing.
Sample config would be like,

Peer table

1.abc.com, 10.10.10.2 , Up
2.abc.com 10.10.10.3, Down
1.xyz.com 11.11.11.2 Up

NAS server group

abcgroup, 1.abc.com
abcgroup, 2.abc.com
xyzgroup, 1.xyz.com

Realm route

abc.com, abcgroup
xyz.com, xyzgroup

answer Jul 25, 2013 by Chandra Javalkar
Similar Questions
+1 vote

Can someone please explain why few "request" message contains Destination-Host and Destination-Realm AVPs and few of them not ?

+3 votes

I am trying to clarify the allowed naming convention for the host and realm of a diameter node. This relates to the values used in the Origin-Host AVP (AVP Code 264) and Origin-Realm AVP (AVP Code 296). I have reviewed the Diameter RFCs and cannot find a definitive answer to this issue.

The reason for asking this question is that I am in discussion with a vendor of a Diameter Routing Agent (DRA) which claims that the host of a diameter node has to be in the format host.realm.
(1) Example of the only allowed format according to the vendor:Origin-Realm: example.com
Origin-Host: node.example.com
I want to clarify if multiple subdomains are allowed to be added in the host without being present in the realm.(2) Example:Origin-Realm: example.com
Origin-Host: node.site1.example.com

According to the vendor, the example 2 is not allowed. To have the host as in example 2, the realm will have to be site1.example.com.
Could someone please clarify this naming issue or point me to the standard where this is defined.

0 votes

In one Diameter blog, I saw a statement in which mentioned, if a Diameter node receive CER from unknown peer it responds back to that peer with Result-Code AVP set to "DIAMETER_UNKNOWN_PEER".
Now my query, Does a Diameter node keep its potential peers information in advance ?

...