Realm Based Routing Table


As we know every node that follows diameter protocol shall maintain two tables 
1) Peer Table
2) Realm-Based Routing Table

As explained earlier,Peer Table shall maintain the Identity of very next peer, that has direct connection to considered peer, state of very next peer (Open,Close,Idle etc.) and how its entry is configured (statically or dynamically).


Realm Routing table shall contain routing and processing information of all peers are present in Peer Table, Such as Realm Name to which a peer belong, Application that are supported by node in that Realm (that is exchanged in CER/CEA), How peer will treat the message e.g. consume LOCALLY if server,forward if Relay etc. 

I would try to explain whole scenario with the help of example but before going for example,shall share some detail about  Realm-Based Routing  Table

In general Relam-Routing table shall have following fields
1) Realm-Name
2) Application-Id
3) Server-Identifier
4) Local-Action
5) Discovery-Type
6) Expiration-Time

Its is not mandatory to use the same name and all the fields when you are implementing Realm-Routing Table. But should maintain all the information according to your implementation.

Now let see what these field contains.
1) Realm-Name -  Its typically act as primary key (not mandatory to make it as PRIMARY KEY (implementation dependent), shall contain the name of realm to peers of considered node are associated.

2) Application Id- shall contain the Application-Ids supported by considered realm exchanged in CER-CEA messages.

3) Server-Identifier(Peer Identity)- Shall contain the Diameter Identity of Peer that is present in Peer-Table for the consider Realm.

4) Local-Action - How the Server-Identity present in the Server-Identity column shall treat the message. This column shall contain one of the following values LOCAL, RELAY, PROXY, REDIRECT.
LOCAL:- Message routed to considered Peer Identity shall be consumed or processed locally and not need to send the message to another server.
RELAY:- Messages MUST be routed to a next hop server of Realm given in Realm-Name column without modifying any non-routing AVPs.
Proxy:- Messages MUST be routed to next hop server of Realm given in Realm-Name column, but this peer identity may apply some local policies by including new AVPs to the message prior to routing.
REDIRECT:- Message sent to this peer MUST return the answer to origin peer without forwarding to any other node.

It is important to note that every peer MUST have atlest one of the LOCAL Actions

5) Discovery Type- this tells whether Rout entry is statically configure or dynamically discovery 

6) Expiration Time- Gives the time at which dynamically discovered rout entries to be expire or needed to be refreshed.


Lets see how a typical Realm Based Routing Table look like
EXAMPLE:-































Consider  Node-A supports four application Ids (1,2,3,4) and all the connections are dynamically configured. Application Ids are advertised in CER/CEA messages. then Peer-Table and Realm-Based routing table should contain following entries.

PEER TABLE

Host
State
Node Discovery
TLS (Security)
Expiration Time
Node-B
Open
Dynamic
Enabled
Node-C
Open
Dynamic
Enabled
Node-E
Open
Dynamic
Enabled


REALM ROUTING TABLE

Realm-Name
Application-Id
Server-Id (Node-Name)
Local Action
Node Discovery
Expiration Time
Realm-1
App-Id-1,2,3,4

LOCAL


Realm-1
App-Id-1
Node-B
LOCAL
Dynamic
Realm-2
App-Id-3
Node-E
PROXY
Dynamic
Realm-2
App-Id-4
Node-E
PROXY
Dynamic
Realm -3
App-Id-2
Node-C
RELAY
Dynamic

*First entry for incoming message at NODE-1.
*If there are two node in a Realm with same features then Destination-Host AVP is used to identify the correct node.

Entries are self-explanatory,Now route at all servers can be identified easily.
All pertaining to rout is their with the node,Using Realm Name and Application Identifier
a message can be sent to destination.


Your Comments /Suggestions and Questions are always welcome.I would try to clarify doubts with best of my knowledge. So feel free to put Questions.

45 comments:

  1. Hi,
    I am novice to Diameter Protocol. First of all I would like to thank you for writing such a wonderful tutorial. Your tutorial has cleared a lot of confusions I had in my mind while reading RFC3588. Now coming to the point I have one doubt regarding Realm based Routing Table. Here in the example Node A has discovered B,C & E as it's peer as specified in the Peer table but in Realm table, for Realm 2 Server ID is mentioned as Node E but application ID's as 3(of NodeF) & 4(of Node G). Similarly for Node C, AppID is 2 (why AppID 5 is not included here as you did in PROXY case).
    My questions may be foolish but as I already said I am very novice just started a few days back.

    Regards,
    Chandra Prakash Jaiswal

    ReplyDelete
    Replies
    1. Hi Chandra Prakash

      Client (Node-A) would not intract with Node-5 because client does not support that Applicaiton (App-5)

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
    2. Can we have multiple Realm with same peer?

      Delete
    3. Ofcourse, You can have multiple Realms with same peer. You just have to maintain Peer FQDN accordingly.
      Its design specific implementation. Design your peer table accordingly so it can cater any proprietary requirement as well.

      Delete
  2. Hi Vinay,

    One more basic doubt is that as per my understanding CER-CEA exchange will happen between each peer nodes. Now suppose I have Peer A, Relay B and Peer C. Peer A is supporting XYZ application ID. So in CER, Peer A will send this App ID to Relay B. Now to transfer the messages correctly, in this scenario Relay B also has to support App ID XYZ. If my understanding is correct, isn't it a limitation from Diameter side that even if RELAY is not applying any business logic over AVP's related to Application, it has to support that App Id resulting in a increased license cost.

    Regards,
    Chandra Prakash Jaiswal

    ReplyDelete
    Replies
    1. Hi Chandra Prakash

      Yes,Your Point is valid.
      Relay must support XYZ application ID if it need to deal with messages of XYZ application. otherwise there is no way to uniquely identify the message and it's purpose.
      Message=[Command Code + Application Id]

      For example.
      In Latest RFC-6733, CER/CEA can be sent with two application ids, 1st base diameter, 2nd Application Id-10 [Ref:- New RFC-6733 (Diameter Base Protocol)]

      As far as Licensing is concern, License is given based on business model. Some give License of PRODUCT (Relay/Server), other gives license of STACK (s6a,s6d etc.).

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  3. Hi, thanks for your message.

    Silly question - how does the NodeA knows that NodeC is a RELAY agent and NodeE is a PROXY agent?

    BR,
    Alexey

    ReplyDelete
  4. Hi Alexey

    Your Question is good, there is no clear cut distinction except it's processing . When you deploy a network then you know what is the next node.

    BUT you can identify based on their application Identifier
    Relay must advertise its Application Identifier (0xffffffff).
    There is no specific application Identifier for Proxy mentioned in standard. Proxy should not publish (0xffffffff)rather should use application Identifier of the application whose messages are being proxied.


    Following link shall help you.
    http://diameter-protocol.blogspot.in/2012/07/diameter-agents.html

    ReplyDelete
  5. Is it Possible to verify table entries as part of troubleshooting as we do for routers? If yes how do can I do that?

    Thanks
    Rajabu

    ReplyDelete
    Replies
    1. Hi Rajabu,

      It is proprietor to STACK implementation of a Vendor. Stack Vendor should have given a provision to see these entries.

      There is no specific command of on Linux/Solaris

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  6. In Realm Routing table, Server-Id is the diameter Id of the peer node. ApplicationId shall contain the appIds after CER-CEA exchange. Now coming to Local Action, on what basis it will configure it as PROXY, REDIRECT, RELAY or LOCAL if it's a dynamic discovery. Broadly it can be subdivided as if in CEA, 0xffffffff will come in supported AddId, then peer can be RELAY/REDIRECT and if some appId's are coming then it can be LOCAL/PROXY but how to finalize within these?

    ReplyDelete
    Replies
    1. HI Chandra Parkas,

      Thanks for highlighting new prospect.
      With your query we are able to correct our understanding.

      Routing Table shall be used in both case when message come(received by) to the node or initiated by the node. In above Table we have missed the entry for Incoming message (If server initiates any message to the client). Entry is added.

      Server-Id and Local-Action is need when node triggers a message.



      Yes in dynamic discovery it is bit vague to identify the Local Action.Because no clear specification is given in RFC-6733.

      While from implementation point of view Relay and Redirect can be distinguished as Redirect node shall not advertise any other application-ID except own. Proxy and Local are more or less same, Because proxy can also emulate Local behavior.

      Thanks for your query.

      Happy to help you again.
      Team-Diameter

      Delete
    2. Thanks for your reply but still I am not clear with the explanation as you have said that "Redirect node shall not advertise any other application-ID except own". As per my knowledge, both RELAY & REDIRECT nodes advertise 0xffffffff as AppId.
      So, on what basis local action will be decided?

      Thanks in advance.

      Delete
  7. In your example above for Realm-2 after the capabilities exchanges from nodes "F" and "G" to node "E" would node E advertise App IDs 3 & 4 in capabilities to node-A?

    ReplyDelete
    Replies
    1. Hi Tom,

      Node-E should advertise App IDs 3 and 4, Because if it doesn't then there is no-way the Node interacting with E shall know about server F and G.

      Although Relay and Proxy can apply local policies to hide and advertise application IDs. For Instance, There is no interaction on application ID 3 then it doesn't make any sense to advertise application ID-3 to A. This infomation is like garbage to A. So during deployment application IDs (Interfaces) on which interaction take place shall only be advertised.

      Delete
  8. Hi,

    Can a Origin-Host have more than one address?

    ReplyDelete
    Replies
    1. Hi Suresh

      No, Origin-Host AVP can not have more than one address.

      Thanks for your query.

      Happy to help you again.
      Team-Diameter

      Delete
  9. HI Team ,

    Thanks for all the information shared and the clarification of each and every query .
    I have a scenario i just want to know how the peer node is routing the diameter message to destination server.

    Its a S6a interface in roaming scenario.

    1. Subscriber from HSS2 of operator2 comes to MME of operator1.
    2. operator 2 has 5 HSS.
    3. MME connected to DEA1 which connected to DEA2 of operator2.
    4. DEA2 is connected all 5 HSS of operator2.
    OP1 OP2
    realm-op1.com realm- op2.com


    MME1-------DEA1--------------DEA2----------HSS1,HSS2,HSS3,HSS4,HSS4,HSS5

    note: HSS1,HSS2,HSS3,HSS4,HSS5 all directly connected to DEA2

    so now the routing part in MME1 we are doing realm based routing . send the diameter message to peer DEA1 for realm op2.com.
    not DEA1 has roaming relation DEA2 which also a peer . so again the routing is realm based which for realm op2.com diameter message goes to DEA2 .
    so the problem is as its realm based routing opertor1 MME is not sending any destination host avp in the diameter messgae just the destination realm .

    So now the question is that how DEA2 is routing the diameter message which should be going to HSS2 .
    I suppose it will use the peer table but realm will be same of all the nodes. Is there any routing condition which is been used in DEA2 (like user-name avp . like for example for user-name avp 1234 then go to HSS2 ) something like that .
    hope i am able to explain it .
    KIndly let me know how exactly the routing will be done on DEA2 to terminate the diameter message to HSS2.

    ReplyDelete
    Replies
    1. Hi Victor,

      thanks for your time and every minute details.

      DEA-2[DRA] will route the message based on value of User-Name AVP. As DRA has right to dip into unique identity AVP User-Name and route message bases on value. Operator can define range at DEA[DRA] for routing message based on User-Name AVP. This is generally done for load balancing.


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  10. Hi,
    I have a basic question.

    What is the basic difference between FQDN and Realm?

    Thanks

    ReplyDelete
    Replies
    1. Hi

      FQDN is a format in which Realm Name shall be given.



      Thanks for your query.
      Happy to help you agin.
      Team-Diameter

      Delete
    2. FQDN is complete address with hostname+realm.. While realm is just a domain in which there could be n number of hosts...

      Isnt it ??

      Delete
  11. HI,
    I am getting RouteException sometimes.
    If i need to re-instatiate the connection automatically between peer .
    Plz suggest me.

    ReplyDelete
    Replies
    1. Hi Srinivas,

      Is node getting Unable to deliver in response? or any thing else. Kindly explain whole scenario, It would be better for us to understand the problem and help you.


      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  12. Hi Team-Diameter,

    Thanks very much for coming up with such a brilliant bunch of pages explaining the Diameter protocol.

    I would like to comment on your reply dated 29th of June 2014, in response to Victor Roy's query.

    When more than one HSS is used in any setup, 3GPP provides the HSS-FE interface Cx/Dh to help learn about the correct HSS. I believe the purpose of the query is, how would the DEA2 learn about HSS2.

    IMHO, the DEA of operator2 would query some HSS FE, using Cx or Dh interface, which is typically a redirect agent. The response should redirect the DEA2 to HSS2.

    Cx is the interface between CSCF-HSS, while Dh is between AS-HSS.

    Let me know what you think of this.

    Cheers

    ReplyDelete
  13. This comment has been removed by the author.

    ReplyDelete
  14. Hi Team ,
    I am new to diameter , I have read that diameter messages pertaining to PEER connection establishment such as CER/CEA have application id 0 , then how we are knowing that waht are the application supported by a node .

    ReplyDelete
    Replies
    1. Hi Naresh Reddy,

      Following link shall help you.

      http://diameter-protocol.blogspot.in/2011/03/capability-negotiation.html

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  15. Hi Team-Diameter,

    Nodes A and B are in different realms. B is acting as a standby to A.
    Once the diameter connections are established, within one diameter session can we switch from A to B? Will the origin-realm change create an issue at the peer side?

    Thanks,
    Harish

    ReplyDelete
    Replies
    1. Hi Harish Ramaprasad,

      Here we want to highlight following points.
      1) Peer shall have Active Diameter Connection with Both A and B but traffic shall be catered on one of the given connections.

      2)In layman term, Realm acts as grouping of Hosts; Ideally it shall not create any impact.

      3)It is deployment specific how you manage switch over cases then there can be multiple ways to manage it.


      Hope above shall help you.

      Thanks for your query.
      Happy to help you again.
      Team-Diameter

      Delete
  16. Hi,
    I've been working on Diameter Protocol I downloaded Free Diameter open source code from http://www.freediameter.net/trac/ . I want to change the entries of Peer Table and Realm Table as per my requirement but I can't seem to find the entries in source code.

    Need help.Thanks in advance.

    ReplyDelete
  17. Hi, I have a question.
    In my application. I have a swx client ( swx1) and two hss nodes ( say hss1 and hss2)
    my scenario is

    hss1 and hss2 is up
    client sends a diameter request & hss1 process the request and responds with AVP

    hss1 is down and hss2 is up
    client sends a diameter requests but the request is not re routed to hss2.
    however, I see that DWR and CEA messages are being exchanged between client and hss2

    My client config xml looks like this












    ReplyDelete
    Replies
    1. Hi Sapna,

      As i understand your problem, my suggestions as below.
      Do your application supports connections with 2 HSS-FE simultaneously.
      If yes, You don't need to send CER again and again. At base diameter peer management is handled. When your one node gets down, Peer management will come to know that one HSS is DOWN, so you don't need to add additinal features. Use rfc 6733 to implement the failover mechanism.

      If No, You need to implement a routing applictaion like DRA to use failover mechanism.

      If it didn't resolve your issues, kindly elaborate with more information (e.g. Client details, configuration setup etc).

      Delete
  18. I am unable to paste my config xml.

    ReplyDelete
  19. If you could please explain, how can I achieve fail over mechanism in Diameter?

    ReplyDelete
  20. Can you please tell me where can I find these tables(peer table and realm routing table) in seagull?

    ReplyDelete
    Replies
    1. Hi Vijay,


      Entries of Peer table and Realm table can be identifed in Configuration file of Seagull.



      Thanks for your query.
      Happy to help you again.

      Delete
  21. Between Destination-Host and Destination-Realm, which does have more priority for routing?

    ReplyDelete
    Replies
    1. Hi Sanjeev,

      This nothing like that which have more priority. Both have their own function. Message check the realm and then host in that realm.

      Its like while finding a location address we first check states and then City in that state.

      Delete
  22. This comment has been removed by the author.

    ReplyDelete
  23. Hello ,

    first of all thanks for this detailed info. Same time am also rookie in diameter so please bear if my question is invalid. In the above example if we consider Application ID 3 , say a CCR request ,the routing would from Node A >> Node E >> Node F. now if node F has to ultimately send the response back to Node A with say CCA. what peer and realm routing table config should be there for Node F. I am confused if an agent has to receive a message it can just be "Local" but in order to sent back messages does it not also have to be specified as a relay or proxy agent.

    ReplyDelete
    Replies
    1. Hi

      Response will follow the same path that is travelled by Request Message.
      so no routing is required for Response message.

      Delete
  24. refering to Oracle DRA .. what is the difference between RBAR and FABR...

    Also in production DRA .. i can see the peerRoutingtable ( defined for home diameter messages) and AppRoutingtable (defined for roamers in visited PLMN).... any use case difference in these two ??

    ReplyDelete
  25. Hi All
    I am new in diameter implementation.. I want to send accounting request to OCS. Can anyone suggest how do get the diameter requests? Can I write my own program to collect the CCR requests? Can someone help me?

    Thanks in advance

    ReplyDelete
  26. Hi All,
    I am facing a problem with a diameter node(PCRF) having peers with same realm.
    If one of the peer goes down then then PCRF hangs. It does not serve requests from peer which is up. How to get around this?

    Thanks.

    ReplyDelete