In conventional DIAMETER networks, there is currently no way for a DIAMETER node, such as a DIAMETER relay node or DIAMETER routing node, to automatically receive information from a peer DIAMETER node indicating which originating hosts or originating realms the peer DIAMETER node should receive particular types of traffic from. Expressed another way, there is currently no mechanism in the DIAMETER specifications that allows a peer DIAMETER node to specify, to a DIAMETER relay or routing node, that when the DIAMETER relay or routing node receives traffic from a particular originating host or originating realm, the traffic should be directed to the peer DIAMETER node. Internet engineering task force (IETF) request for comments (RFCs) 3588 and 3589 are incorporated herein by reference in their entireties. For example, in the event that network operator X signs an agreement with operator Y that all traffic transmitted through hub provider A's network should be routed to operator X's realm, it may be desirable for operator X to automatically notify hub provider A of the agreement between operator X and operator Y so that hub provider A can update its routing tables accordingly.
Currently, in the exemplary scenario described above, hub provider A must manually gather origin-based routing information and update its routing tables. For example, a human user may be required to manually log into a terminal associated with one or more DIAMETER nodes in the hub provider's network and add origin-based rules to the routing tables.
While no method currently exists for automatically notifying and updating the routing tables of a DIAMETER node with origin-based routing information, conventional solutions exist for automatic notification and routing table updating for destination-based routing information. Currently, this is accomplished using the domain name system (DNS). For example, if network operator X wishes to know the networks (i.e., realms or hosts) to which he can route traffic, operator X sends a DNS query to a DNS server that maintains this information. Based on the information included in the DNS response, network operator X (i.e., the DIAMETER node in realm X that initiated the DNS query) may automatically update its routing tables with the destination-based routing information.
As may be appreciated from the above discussion, one drawback to conventional methods for populating or updating routing information in DIAMETER nodes is that automatic routing table population is only available for destination-based routing information. As a result, a corollary drawback of conventional methods is therefore that populating and/or updating routing information for DIAMETER nodes is a manual process that may be slow and prone to error.
Accordingly, in light of these difficulties, a need exists for improved methods, systems, and computer readable media for automatically populating and/or updating routing tables of DIAMETER nodes with origin-based routing information.