US20190288983A1 - Routing Agent Platform with a 3-Tier Architecture for Diameter Communication Protocol in IP Networks - Google Patents
Routing Agent Platform with a 3-Tier Architecture for Diameter Communication Protocol in IP Networks Download PDFInfo
- Publication number
- US20190288983A1 US20190288983A1 US16/353,581 US201916353581A US2019288983A1 US 20190288983 A1 US20190288983 A1 US 20190288983A1 US 201916353581 A US201916353581 A US 201916353581A US 2019288983 A1 US2019288983 A1 US 2019288983A1
- Authority
- US
- United States
- Prior art keywords
- dlb
- dcr
- peer
- address
- message
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2539—Hiding addresses; Keeping addresses anonymous
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/302—Route determination based on requested QoS
- H04L45/304—Route determination for signalling traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/74—Address processing for routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
-
- H04L61/2507—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/256—NAT traversal
- H04L61/2567—NAT traversal for reachability, e.g. inquiring the address of a correspondent behind a NAT server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/2514—Translation of Internet protocol [IP] addresses between local and global IP addresses
Definitions
- This invention relates generally to the field of telecommunications networks, specifically to the Diameter Protocol in Internet Protocol (IP) network.
- IP Internet Protocol
- DRA Diameter Routing Agent
- Diameter protocol in IP network is defined by the following standards: IETF RFC 3588 and RFC 6733. Diameter is a communication protocol widely used in telecommunications for authentication, authorization and accounting. It is adopted by 3rd Generation Partnership Project (3GPP) as the communication standard for many interfaces for mobile networks, including S6a/S6d, S9, Sh, Cx, Dx, Gx, Gy/Ro, and others.
- 3GPP 3rd Generation Partnership Project
- Diameter may run over Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) transport protocols, which in turn run over IP networks.
- TCP Transmission Control Protocol
- SCTP Stream Control Transmission Protocol
- Diameter is a client-server protocol. Diameter requests are sent from a client to a server, and answers are sent from a server to a client.
- RFC3588/6733 defines Diameter Agents as Relay Agents, Proxy Agents, Redirect Agents and Translation Agents. They are also commonly known as Diameter Routing Agents (DRA).
- DAA Diameter Routing Agents
- a DRA may perform message mediation on both request and answer messages, such as adding, modifying, or deleting an Attribute-Value-Pair (AVP).
- AVP Attribute-Value-Pair
- a Diameter request and answer message pair is collectively referred to as a Diameter transaction.
- a typical flow of a Diameter transaction that traverses a DRA 1) receives a request; 2) performs message mediation, if necessary; 3) makes routing decision; 4) performs message mediation, if necessary; 5) sends request to the destination; 6) receives an answer; 7) performs message mediation, if necessary; 8) routes the answer to the Peer from which the request was received.
- any one of the Peers may send requests to any other Peer.
- any Peer must be able to send messages to any other Peer connected to the DRA.
- a Peer may send hundreds or thousands of transactions-per-second (TPS).
- TPS transactions-per-second
- a typical TCP/SCTP load balancer does not work in Diameter protocol applications because in the Diameter protocol, two Peers must first establish a session through Capability-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) procedure.
- CER Capability-Exchange-Request
- CEA Capabilities-Exchange-Answer
- a TCP/SCTP load balancer that simply routes Diameter requests to a DRA does not ensure the CER/CEA procedure was successfully completed between an external Peer and every DRA.
- a load balancer may not be able to handle the required capacity. Having multiple load balancers is not a viable solution because the DRA must expose a single IP to all external Peers so that the internal topology is hidden from external entities.
- the invention pertains to a high-performance DRA with a 3-tier architecture to handle traffic capacity in a large-scale deployment.
- the 3-tier architecture involves 1) a Diameter Connection Router (DCR), 2) multiple Diameter Load Balancer (DLB), and 3) multiple DRA instances.
- DCR Diameter Connection Router
- DLB Diameter Load Balancer
- DCR is a front-end module that interfaces with all external Peers.
- all external Peers send messages to the public IP address of the DCR.
- all outgoing message from the DRA platform to external Peer use the source IP address of DCR.
- DCR Upon a new connection request from external Peers, DCR selects a DLB and routes the connection to the DLB. In other words, the DCR acts as a load balancer and distributes incoming connections to DLB.
- Diameter connections for DLB ⁇ > external—Peer and DLB ⁇ > DRA is one-to-many.
- DRA is the entity that makes routing decision for Diameter requests.
- Diameter-server->DCR->DLB->DRA->DLB->DCR->Diameter-client 1) request: Diameter-client->DCR->DLB->DRA->DLB->DCR->Diameter-server, 2) answer: Diameter-server->DCR->DLB->DRA->DLB->DCR->Diameter-client.
- each DRA may handle thousands of TPS, whereas each DLB may handle tens of thousands of TPS, and each DCR may handle hundreds of thousands of TPS of Diameter transactions.
- the invention pertains to a method and system for routing messages using Diameter Protocol.
- the DCR is a frontend module interfacing with a plurality of peers external to the computer network.
- the public IP address of the DCR is exposed to the external peers as a single point of contact to the computer network, therefore, hiding an internal topology of the computer network from the peers.
- Each DLB is in communication with the DCR, and each DLB is connected to each of the plurality of the DRAs. This one-to-many connection enables a message from an external peer to reach any DRA.
- the DCR selects one of the DLBs and routs the message to that DLB. All subsequent messages from the first peer bypass the DCR and are routed from the first peer to the selected DLB. The DLB then routes the message to one of the DRAs.
- the DRA identifies a second DLB that has a routing path to the destination external peer and routes the message to the second DLB. The second DLB routes the message to the DCR, which then routes the message to the destination peer.
- the DCR performs destination-Network Address Translation (NAT) to translate a destination IP address of the message from the public IP address of the DCR to an IP address of the DLB.
- NAT destination-Network Address Translation
- the DCR prior to routing the message to the second peer, performs source-NAT to translate a source IP address of the message from the IP address of the second DLB to the public IP address of the DCR.
- the DLB performs a Stream Control Transmission Protocol (SCTP)-layer NAT to translate the IPv4Address parameter of the message from an IP address of the second DLB to the public IP address of the DCR.
- SCTP Stream Control Transmission Protocol
- the DLB is configured to monitor the availability of each of the plurality of DRAs and remove an unavailable DRA from the pool of DRAs available for traffic distribution.
- the DRA determines a routing path for routing the message to the second peer.
- the DRA may perform message mediation using a rule-engine.
- the rule-engine may involve an attribute selected from Diameter headers, Attribute-Value-Pair (AVP) of the message, and/or an identity of the source peer.
- AVP Attribute-Value-Pair
- the DCR implements initial packet handling of the message using ‘Netfilter’ in LINUX operating system and implements Network Address Translation using ‘iptable’ in LINUX operating system.
- one of the DLBs detects that all connections between the first DLB and the plurality of the DRAs are broken, the DLB terminates the connection with the source peer. If the DCR receives a request to teardown a connection with a peer, the DCR issues a command to delete a rule requiring that all subsequent messages from that peer bypass the DCR and are routed to the first DLB.
- FIG. 1 is a block diagram schematically depicting the logical architecture of an embodiment of the present invention.
- FIG. 2 is a block diagram schematically depicting the IP layer routing and Network Address Translation (NAT) operations of the present invention.
- NAT Network Address Translation
- FIG. 3 is a block diagram schematically depicting the SCTP-layer routing and Network Address Translation (NAT) operations of the present invention.
- FIG. 4 is a block diagram schematically depicting the network connections between DCR, DLB and DRA.
- FIG. 5 is a block diagram schematically depicting the connection establishment flow at DCR.
- FIG. 6 is a block diagram schematically depicting the connection teardown flow at DCR.
- FIG. 7 is a diagram schematically depicting the DCR IP-layer NAT table.
- FIG. 8 is a block diagram schematically depicting the DCR IP-Table processing in a Linux operating system.
- FIG. 9 is a block diagram schematically depicting the Diameter connections establishments mapping of the present invention.
- FIG. 10 is a block diagram schematically depicting the Diameter transaction flow of the present invention.
- FIG. 11 is a sequential diagram schematically depicting a message flow of SCTP establishment and teardown procedure when the DRA platform is acting as client.
- FIG. 12 is a sequential diagram schematically depicting a message flow of Diameter transaction when the DRA platform is acting as client.
- FIG. 13 is a sequential diagram schematically depicting a message flow of SCTP establishment and teardown procedure when the DRA platform is acting as server.
- FIG. 14 is a sequential diagram schematically depicting a message flow of Diameter transaction when the DRA platform is acting as server.
- the invention is a specialized networking and application system that handles routing of Diameter messages between Diameter clients and Peers (generally referred to as ‘Peers’).
- the present invention is a high-performance Diameter Routing Agent (DRA) Platform 10 that consists of Diameter Connection Router (DCR) 12 , Diameter Load Balancer (DLB) 14 , and Diameter Routing Agent (DRA) 16 .
- DCR Diameter Connection Router
- DLB Diameter Load Balancer
- DAA Diameter Routing Agent
- DCR 12 distributes an incoming Diameter connection from a Peer 18 to one of DLBs 14 .
- DLB 14 establishes a corresponding connection to each DRA 16 .
- each DRA 16 when DRA Platform 10 acts as client, each DRA 16 establishes a connection with DLB 14 .
- DLB 14 then establishes a corresponding connection to remote Peer 18 , via the DCR 12 .
- FIG. 2 depicts the IP-layer Network Address Translation (NAT) performed by DCR 12 to route messages between external and internal networks.
- Peer 18 has IP address 20
- DCR 12 has an IP address 22
- DLB 14 has an IP address 24
- DRA 16 has an IP address 26 .
- IP address 22 of DCR 12 is public and advertised to external Peer 18 as the single point of contact to DRA Platform 10 .
- DCR 12 upon receiving a new SCTP/TCP connection request packet from external Peer 18 , DCR 12 selects one of DLBs 14 to handle this connection.
- DCR 12 performs a destination-NAT to translate the destination IP from DCR 12 IP address 22 to DLB 14 IP address 24 .
- standard IP routing is used for routing the packet from DLB 14 to DRA 12 . Subsequent incoming IP packets of the same flow from Peer 18 to DRA 16 will follow the same path and logic.
- step 108 standard IP routing is used to route an outgoing IP packet from DRA 16 to DLB 14 .
- step 110 DLB 14 routes the outgoing IP packet to DCR 12 by next-hop gateway.
- DCR 12 Upon receiving the outgoing IP packet from DLB 14 , DCR 12 performs a source-NAT, in step 112 , to translate the source IP from DLB IP address 24 to DCR IP address 22 .
- the outgoing packet is then routed to Peer 18 .
- FIG. 3 depicts an embodiment, in which the SCTP-layer NAT performed by DLB 14 in routing messages between external and internal networks.
- An outgoing SCTP INIT or INIT_ACK chunk 28 from DLB 12 main application contains its own IP address in IPv4Address parameter.
- a ‘sctpnat’ module 30 in DLB node performs NAT to translate the IPv4Address parameter from DLB IP address 24 to DCR IP address 22 .
- the outgoing INIT or INIT_ACK chunk from DCR 12 to external Peer 18 will contain DCR IP address 22 in the IPv4Address parameter.
- SCTP INIT or INIT_ACK NAT may be performed in DLB 12 main application.
- FIG. 4 depicts an exemplary network connections mapping between DCR 12 , DLB- 1 14 a , DLB- 2 14 b , DRA- 1 16 a , and DRA- 2 16 b .
- Each connection between DCR 12 and one of external Peers 18 (in this example, 18 a , 18 b , or 18 c ) will have a single corresponding connection to one of available DLBs 16 (in this example, either DLB- 1 14 a or DLB- 2 14 b ).
- Each connection between DCR 12 and one of DLBs 14 will have a corresponding connection to every DRA 16 (in this example, DRA- 1 16 a and DRA- 2 16 b ).
- each DRA 16 to reach any external Peer 18 ( 18 a , 18 b , or 18 c ) through one of the DLBs 14 and then DCR 12 .
- each external Peer 18 has an indirect connection to every DRA 16 regardless of which DLB 14 used.
- FIG. 5 depicts an exemplary DCR 12 connection establishment flow for DRA Platform 10 acting as server with a Linux implementation.
- DCR node Upon receiving an incoming SCTP_INIT packet from an external Peer 18 , DCR node has an iptable configuration 32 that routes the packet to DCR application 12 via Netfilter library 34 .
- DCR application 12 executes an internal logic (such as round-robin) to determine which DLB 14 shall handle this connection. Having selected a DLB 14 , DCR 12 application will then insert a rule to iptable 32 to route subsequent packets of the same flow to DLB 14 . Subsequent packets will then be directly exchanged between external Peer 18 and DLB 14 , bypassing DCR application 12 .
- SCTP packet handling may be performed natively in DCR 12 machine OS kernel or as an application running in user space.
- FIG. 6 depicts an exemplary connection teardown flow for DRA Platform 10 .
- Peer 18 sends a SCTP ABORT or SHUTDOWN packet to DCR 12 .
- DCR 12 has an iptable 32 configuration that routes the packet to DCR application 12 via Netfilter library 34 .
- DCR application 12 then issues a command to delete the rule in iptable 32 for routing traffic (between external Peer 18 and DLB 14 ) of this connection.
- FIG. 7 depicts the detailed IP-layer NAT operations performed in DCR 12 . There are four scenarios, which are as follows:
- FIG. 8 depicts an embodiment, in which NAT is implemented using iptable 32 in a Linux environment.
- Ingress packet handler 36 is performed with a ‘Pre-routing’ rule in ‘Mangle’ table.
- Ingress destination-NAT 40 is performed with a ‘Pre-routing’ rule in ‘NAT’ table 42 .
- Egress packet handler 40 is performed with a ‘Post-routing’ rule in ‘Mangle’ table 46 .
- Egress source-NAT 48 is performed with a ‘Post-routing’ rule in ‘NAT’ table 50 .
- source or destination NAT may be performed natively in the DCR machine OS kernel or as an application running in user space.
- FIG. 9 depicts an exemplary Diameter connections synchronization among the nodes of DRA Platform 10 .
- Diameter Capabilities-Exchange-Request/Capabilities-Exchange-Answer happens between external Peer 18 and DLB 14 , and between DLB 14 and DRA 16 .
- CER/CEA Diameter Capabilities-Exchange-Request/Capabilities-Exchange-Answer
- FIG. 10 depicts an exemplary Diameter Transaction Flow.
- An incoming Diameter request from source Peer-A 18 a arrives at DCR 12 .
- DCR 12 routes the request to DLB- 1 14 a , which in turn routes the request to DRA- 1 16 a .
- DRA- 1 16 a determines destination Peer-B 18 b for this request and routes the request to Peer-B 18 b .
- Peer-B 18 b is connected to DRA- 1 16 a via DLB- 2 14 b .
- DLB- 2 14 b routes the request to destination Peer-B 18 b via DCR 12 .
- the Diameter answer follows the reverse path as in standard Diameter routing.
- FIGS. 11-14 are sequential diagrams schematically depicting exemplary message flow in various scenarios.
- FIGS. 11 and 12 depict scenarios in which DRA Platform 10 acts as a client. Specifically, FIG. 11 depicts a message flow of SCTP establishment and teardown procedure, and FIG. 12 depicts a message flow of Diameter transaction—in both scenarios DRA Platform 10 acts as client.
- FIGS. 13 and 14 depict scenarios in which DRA Platform 10 acts a server. Specifically, FIG. 13 is a sequential diagram schematically depicting a message flow of SCTP establishment and teardown procedure, and FIG. 14 depicts a message flow of Diameter transaction—in both scenarios DRA Platform 10 acts as server.
- the present invention may be embodied on various platforms.
- the following provides an antecedent basis for the information technology that may be utilized to enable the invention.
- Embodiments of the present invention may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the present invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors.
- a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device).
- a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others.
- firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.
- the machine-readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
- a computer readable storage medium may be any non-transitory, tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
- a machine-readable signal medium may include a propagated data signal with machine-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
- a machine-readable signal medium may be any machine-readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
- claims to this invention as a software product are those embodied in a non-transitory software medium such as a computer hard drive, flash-RAM, optical disk or the like.
- Machine-readable program code embodied on a machine-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire-line, optical fiber cable, radio frequency, etc., or any suitable combination of the foregoing.
- Machine-readable program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C#, C++, Visual Basic or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
Abstract
Description
- This invention relates generally to the field of telecommunications networks, specifically to the Diameter Protocol in Internet Protocol (IP) network.
- More specifically, it relates to methods and systems of building a high-performance Diameter Routing Agent (DRA) Platform with a 3-tier architecture.
- Diameter protocol in IP network is defined by the following standards: IETF RFC 3588 and RFC 6733. Diameter is a communication protocol widely used in telecommunications for authentication, authorization and accounting. It is adopted by 3rd Generation Partnership Project (3GPP) as the communication standard for many interfaces for mobile networks, including S6a/S6d, S9, Sh, Cx, Dx, Gx, Gy/Ro, and others.
- Diameter may run over Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) transport protocols, which in turn run over IP networks.
- Diameter is a client-server protocol. Diameter requests are sent from a client to a server, and answers are sent from a server to a client.
- RFC3588/6733 defines Diameter Agents as Relay Agents, Proxy Agents, Redirect Agents and Translation Agents. They are also commonly known as Diameter Routing Agents (DRA).
- A DRA may perform message mediation on both request and answer messages, such as adding, modifying, or deleting an Attribute-Value-Pair (AVP).
- A Diameter request and answer message pair is collectively referred to as a Diameter transaction.
- A typical flow of a Diameter transaction that traverses a DRA: 1) receives a request; 2) performs message mediation, if necessary; 3) makes routing decision; 4) performs message mediation, if necessary; 5) sends request to the destination; 6) receives an answer; 7) performs message mediation, if necessary; 8) routes the answer to the Peer from which the request was received.
- In a typical large-scale deployment of DRA, there may be hundreds, or thousands of Diameter Peers connecting to the DRA, any one of the Peers may send requests to any other Peer. In other words, any Peer must be able to send messages to any other Peer connected to the DRA. In a typical large-scale deployment of DRA, a Peer may send hundreds or thousands of transactions-per-second (TPS). The aggregated traffic capacity from all Peers may well exceed what can be handled by a single instance of DRA application or server.
- A typical TCP/SCTP load balancer does not work in Diameter protocol applications because in the Diameter protocol, two Peers must first establish a session through Capability-Exchange-Request (CER) and Capabilities-Exchange-Answer (CEA) procedure. A TCP/SCTP load balancer that simply routes Diameter requests to a DRA does not ensure the CER/CEA procedure was successfully completed between an external Peer and every DRA. Moreover, a load balancer may not be able to handle the required capacity. Having multiple load balancers is not a viable solution because the DRA must expose a single IP to all external Peers so that the internal topology is hidden from external entities.
- In an embodiment, the invention pertains to a high-performance DRA with a 3-tier architecture to handle traffic capacity in a large-scale deployment. The 3-tier architecture involves 1) a Diameter Connection Router (DCR), 2) multiple Diameter Load Balancer (DLB), and 3) multiple DRA instances.
- DCR is a front-end module that interfaces with all external Peers. In other words, all external Peers send messages to the public IP address of the DCR. On the other hand, all outgoing message from the DRA platform to external Peer use the source IP address of DCR.
- Upon a new connection request from external Peers, DCR selects a DLB and routes the connection to the DLB. In other words, the DCR acts as a load balancer and distributes incoming connections to DLB.
- For every Diameter connection with external Peer, DLB establishes a corresponding connection with each DRA. In other words, Diameter connections for DLB < > external—Peer and DLB < > DRA is one-to-many.
- DRA is the entity that makes routing decision for Diameter requests.
- The complete flow of a Diameter transaction is as follows: 1) request: Diameter-client->DCR->DLB->DRA->DLB->DCR->Diameter-server, 2) answer: Diameter-server->DCR->DLB->DRA->DLB->DCR->Diameter-client.
- In a typical installation, each DRA may handle thousands of TPS, whereas each DLB may handle tens of thousands of TPS, and each DCR may handle hundreds of thousands of TPS of Diameter transactions.
- In an embodiment, the invention pertains to a method and system for routing messages using Diameter Protocol. In this embodiment, the DCR is a frontend module interfacing with a plurality of peers external to the computer network. The public IP address of the DCR is exposed to the external peers as a single point of contact to the computer network, therefore, hiding an internal topology of the computer network from the peers.
- Multiple DLBs are in communication with the DCR, and each DLB is connected to each of the plurality of the DRAs. This one-to-many connection enables a message from an external peer to reach any DRA.
- When a first external peer sends a message to the public IP of the DCR, the DCR selects one of the DLBs and routs the message to that DLB. All subsequent messages from the first peer bypass the DCR and are routed from the first peer to the selected DLB. The DLB then routes the message to one of the DRAs. The DRA identifies a second DLB that has a routing path to the destination external peer and routes the message to the second DLB. The second DLB routes the message to the DCR, which then routes the message to the destination peer.
- In an embodiment, the DCR performs destination-Network Address Translation (NAT) to translate a destination IP address of the message from the public IP address of the DCR to an IP address of the DLB. In another aspect of the invention, prior to routing the message to the second peer, the DCR performs source-NAT to translate a source IP address of the message from the IP address of the second DLB to the public IP address of the DCR.
- In an embodiment, the DLB performs a Stream Control Transmission Protocol (SCTP)-layer NAT to translate the IPv4Address parameter of the message from an IP address of the second DLB to the public IP address of the DCR.
- In an embodiment, the DLB is configured to monitor the availability of each of the plurality of DRAs and remove an unavailable DRA from the pool of DRAs available for traffic distribution.
- The DRA determines a routing path for routing the message to the second peer. The DRA may perform message mediation using a rule-engine. The rule-engine may involve an attribute selected from Diameter headers, Attribute-Value-Pair (AVP) of the message, and/or an identity of the source peer.
- In an embodiment, the DCR implements initial packet handling of the message using ‘Netfilter’ in LINUX operating system and implements Network Address Translation using ‘iptable’ in LINUX operating system.
- In an embodiment, one of the DLBs detects that all connections between the first DLB and the plurality of the DRAs are broken, the DLB terminates the connection with the source peer. If the DCR receives a request to teardown a connection with a peer, the DCR issues a command to delete a rule requiring that all subsequent messages from that peer bypass the DCR and are routed to the first DLB.
- For a fuller understanding of the invention, reference should be made to the following detailed disclosure, taken in connection with the accompanying drawings, in which:
-
FIG. 1 is a block diagram schematically depicting the logical architecture of an embodiment of the present invention. -
FIG. 2 is a block diagram schematically depicting the IP layer routing and Network Address Translation (NAT) operations of the present invention. -
FIG. 3 is a block diagram schematically depicting the SCTP-layer routing and Network Address Translation (NAT) operations of the present invention. -
FIG. 4 is a block diagram schematically depicting the network connections between DCR, DLB and DRA. -
FIG. 5 is a block diagram schematically depicting the connection establishment flow at DCR. -
FIG. 6 is a block diagram schematically depicting the connection teardown flow at DCR. -
FIG. 7 is a diagram schematically depicting the DCR IP-layer NAT table. -
FIG. 8 is a block diagram schematically depicting the DCR IP-Table processing in a Linux operating system. -
FIG. 9 is a block diagram schematically depicting the Diameter connections establishments mapping of the present invention. -
FIG. 10 is a block diagram schematically depicting the Diameter transaction flow of the present invention. -
FIG. 11 is a sequential diagram schematically depicting a message flow of SCTP establishment and teardown procedure when the DRA platform is acting as client. -
FIG. 12 is a sequential diagram schematically depicting a message flow of Diameter transaction when the DRA platform is acting as client. -
FIG. 13 is a sequential diagram schematically depicting a message flow of SCTP establishment and teardown procedure when the DRA platform is acting as server. -
FIG. 14 is a sequential diagram schematically depicting a message flow of Diameter transaction when the DRA platform is acting as server. - In the embodiment depicted in
FIG. 1 , the invention is a specialized networking and application system that handles routing of Diameter messages between Diameter clients and Peers (generally referred to as ‘Peers’). - The present invention is a high-performance Diameter Routing Agent (DRA)
Platform 10 that consists of Diameter Connection Router (DCR) 12, Diameter Load Balancer (DLB) 14, and Diameter Routing Agent (DRA) 16. - In the embodiment depicted in
FIG. 1 , when theDRA Platform 10 acts as server,DCR 12 distributes an incoming Diameter connection from aPeer 18 to one ofDLBs 14. When a first connection, viaDCR 12, is established betweenremote Peer 18 andDLB 14,DLB 14 establishes a corresponding connection to eachDRA 16. - In the embodiment depicted in
FIG. 1 , whenDRA Platform 10 acts as client, eachDRA 16 establishes a connection withDLB 14.DLB 14 then establishes a corresponding connection toremote Peer 18, via theDCR 12. -
FIG. 2 depicts the IP-layer Network Address Translation (NAT) performed byDCR 12 to route messages between external and internal networks.Peer 18 hasIP address 20,DCR 12 has anIP address 22,DLB 14 has anIP address 24, andDRA 16 has anIP address 26. -
IP address 22 ofDCR 12 is public and advertised toexternal Peer 18 as the single point of contact toDRA Platform 10. Referring toFIG. 2 , instep 102, upon receiving a new SCTP/TCP connection request packet fromexternal Peer 18,DCR 12 selects one ofDLBs 14 to handle this connection. Instep 104,DCR 12 performs a destination-NAT to translate the destination IP fromDCR 12IP address 22 to DLB 14IP address 24. Instep 106, standard IP routing is used for routing the packet fromDLB 14 toDRA 12. Subsequent incoming IP packets of the same flow fromPeer 18 toDRA 16 will follow the same path and logic. - In
step 108, standard IP routing is used to route an outgoing IP packet fromDRA 16 toDLB 14. Instep 110,DLB 14 routes the outgoing IP packet toDCR 12 by next-hop gateway. Upon receiving the outgoing IP packet fromDLB 14,DCR 12 performs a source-NAT, instep 112, to translate the source IP fromDLB IP address 24 toDCR IP address 22. The outgoing packet is then routed toPeer 18. -
FIG. 3 depicts an embodiment, in which the SCTP-layer NAT performed byDLB 14 in routing messages between external and internal networks. An outgoing SCTP INIT orINIT_ACK chunk 28 fromDLB 12 main application contains its own IP address in IPv4Address parameter. Instep 114, a ‘sctpnat’module 30 in DLB node performs NAT to translate the IPv4Address parameter fromDLB IP address 24 toDCR IP address 22. As a result, the outgoing INIT or INIT_ACK chunk fromDCR 12 toexternal Peer 18 will containDCR IP address 22 in the IPv4Address parameter. - In other embodiments, SCTP INIT or INIT_ACK NAT may be performed in
DLB 12 main application. -
FIG. 4 depicts an exemplary network connections mapping betweenDCR 12, DLB-1 14 a, DLB-2 14 b, DRA-1 16 a, and DRA-2 16 b. Each connection betweenDCR 12 and one of external Peers 18 (in this example, 18 a, 18 b, or 18 c) will have a single corresponding connection to one of available DLBs 16 (in this example, either DLB-1 14 a or DLB-2 14 b). Each connection betweenDCR 12 and one ofDLBs 14 will have a corresponding connection to every DRA 16 (in this example, DRA-1 16 a and DRA-2 16 b). This scheme enables eachDRA 16 to reach any external Peer 18 (18 a, 18 b, or 18 c) through one of theDLBs 14 and thenDCR 12. In other words, eachexternal Peer 18 has an indirect connection to everyDRA 16 regardless of which DLB 14 used. -
FIG. 5 depicts anexemplary DCR 12 connection establishment flow forDRA Platform 10 acting as server with a Linux implementation. Upon receiving an incoming SCTP_INIT packet from anexternal Peer 18, DCR node has aniptable configuration 32 that routes the packet toDCR application 12 viaNetfilter library 34.DCR application 12 then executes an internal logic (such as round-robin) to determine which DLB 14 shall handle this connection. Having selected aDLB 14,DCR 12 application will then insert a rule to iptable 32 to route subsequent packets of the same flow toDLB 14. Subsequent packets will then be directly exchanged betweenexternal Peer 18 andDLB 14, bypassingDCR application 12. - In other embodiments, SCTP packet handling may be performed natively in
DCR 12 machine OS kernel or as an application running in user space. -
FIG. 6 depicts an exemplary connection teardown flow forDRA Platform 10. When anexternal Peer 18 orDLB 14 decides to teardown a connection,Peer 18 sends a SCTP ABORT or SHUTDOWN packet toDCR 12. Upon receiving this packet,DCR 12 has an iptable 32 configuration that routes the packet toDCR application 12 viaNetfilter library 34.DCR application 12 then issues a command to delete the rule iniptable 32 for routing traffic (betweenexternal Peer 18 and DLB 14) of this connection. -
FIG. 7 depicts the detailed IP-layer NAT operations performed inDCR 12. There are four scenarios, which are as follows: -
- 1)
DRA Platform 10 acting as server and routing an ingress packet. When an ingress packet is received fromexternal Peer 18,DCR 12 will perform a destination NAT to translate the destination IP fromDCR IP address 22 toDLB IP address 24. - 2)
DRA Platform 10 acting as server and routing an egress packet, When an egress packet is received fromDLB 14,DCR 12 will perform a source NAT to translate the source IP fromDLB IP address 24 toDCR IP address 22. - 3)
DRA Platform 10 acting as client and routing an ingress packet. When an ingress packet is received from external Peer, DCR will perform a destination NAT to translate the destination IP fromDCR IP address 22 toDLB IP address 24. - 4)
DRA Platform 10 acting as client and routing an egress packet. When an egress packet is received from DLB, DCR will perform a source NAT to translate the source IP fromDLB IP address 24 toDCR IP address 22.
- 1)
-
FIG. 8 depicts an embodiment, in which NAT is implemented usingiptable 32 in a Linux environment.Ingress packet handler 36 is performed with a ‘Pre-routing’ rule in ‘Mangle’ table. Ingress destination-NAT 40 is performed with a ‘Pre-routing’ rule in ‘NAT’ table 42.Egress packet handler 40 is performed with a ‘Post-routing’ rule in ‘Mangle’ table 46. Egress source-NAT 48 is performed with a ‘Post-routing’ rule in ‘NAT’ table 50. - In other embodiments, source or destination NAT may be performed natively in the DCR machine OS kernel or as an application running in user space.
-
FIG. 9 depicts an exemplary Diameter connections synchronization among the nodes ofDRA Platform 10. For every Diameter connection established between anexternal Peer 18 andDLB 14, there is a corresponding Diameter connection between that DLB 14 and everyDRA 16. Diameter Capabilities-Exchange-Request/Capabilities-Exchange-Answer (CER/CEA) happens betweenexternal Peer 18 andDLB 14, and betweenDLB 14 andDRA 16. When a Diameter connection is broken betweenDLB 14 and oneDRA 16,DLB 14 and thatDRA 16 will attempt to re-establish the connection (as long as at least oneother DRA 16 remains connected to DLB 14). When all Diameter connections betweenDLB 14 and everyDRA 16 are broken, the corresponding connection betweenexternal Peer 18 andDLB 14 will be disconnected byDLB 14. When Diameter connection betweenexternal Peer 18 andDLB 14 is broken, the corresponding connections betweenDLB 14 and everyDRA 16 will be disconnected byDLB 14. -
FIG. 10 depicts an exemplary Diameter Transaction Flow. An incoming Diameter request from source Peer-A 18 a arrives atDCR 12.DCR 12 routes the request to DLB-1 14 a, which in turn routes the request to DRA-1 16 a. DRA-1 16 a determines destination Peer-B 18 b for this request and routes the request to Peer-B 18 b. Peer-B 18 b is connected to DRA-1 16 a via DLB-2 14 b. DLB-2 14 b routes the request to destination Peer-B 18 b viaDCR 12. The Diameter answer follows the reverse path as in standard Diameter routing. -
FIGS. 11-14 are sequential diagrams schematically depicting exemplary message flow in various scenarios.FIGS. 11 and 12 depict scenarios in whichDRA Platform 10 acts as a client. Specifically,FIG. 11 depicts a message flow of SCTP establishment and teardown procedure, andFIG. 12 depicts a message flow of Diameter transaction—in bothscenarios DRA Platform 10 acts as client.FIGS. 13 and 14 depict scenarios in whichDRA Platform 10 acts a server. Specifically,FIG. 13 is a sequential diagram schematically depicting a message flow of SCTP establishment and teardown procedure, andFIG. 14 depicts a message flow of Diameter transaction—in bothscenarios DRA Platform 10 acts as server. - The present invention may be embodied on various platforms. The following provides an antecedent basis for the information technology that may be utilized to enable the invention.
- Embodiments of the present invention may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the present invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.
- The machine-readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any non-transitory, tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
- A machine-readable signal medium may include a propagated data signal with machine-readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A machine-readable signal medium may be any machine-readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. However, as indicated above, due to circuit statutory subject matter restrictions, claims to this invention as a software product are those embodied in a non-transitory software medium such as a computer hard drive, flash-RAM, optical disk or the like.
- Program code embodied on a machine-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire-line, optical fiber cable, radio frequency, etc., or any suitable combination of the foregoing. Machine-readable program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C#, C++, Visual Basic or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
- Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by machine-readable program instructions.
- The advantages set forth above, and those made apparent from the foregoing disclosure, are efficiently attained. Since certain changes may be made in the above construction without departing from the scope of the invention, it is intended that all matters contained in the foregoing disclosure or shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
Claims (19)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/353,581 US10432583B1 (en) | 2018-03-14 | 2019-03-14 | Routing agent platform with a 3-tier architecture for diameter communication protocol in IP networks |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201862642906P | 2018-03-14 | 2018-03-14 | |
US16/353,581 US10432583B1 (en) | 2018-03-14 | 2019-03-14 | Routing agent platform with a 3-tier architecture for diameter communication protocol in IP networks |
Publications (2)
Publication Number | Publication Date |
---|---|
US20190288983A1 true US20190288983A1 (en) | 2019-09-19 |
US10432583B1 US10432583B1 (en) | 2019-10-01 |
Family
ID=67904236
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/353,581 Active US10432583B1 (en) | 2018-03-14 | 2019-03-14 | Routing agent platform with a 3-tier architecture for diameter communication protocol in IP networks |
Country Status (1)
Country | Link |
---|---|
US (1) | US10432583B1 (en) |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8613073B2 (en) * | 2009-10-16 | 2013-12-17 | Tekelec, Inc. | Methods, systems, and computer readable media for providing diameter signaling router with firewall functionality |
US8750126B2 (en) * | 2009-10-16 | 2014-06-10 | Tekelec, Inc. | Methods, systems, and computer readable media for multi-interface monitoring and correlation of diameter signaling information |
WO2011100600A2 (en) * | 2010-02-12 | 2011-08-18 | Tekelec | Methods, systems and computer readable media for providing priority routing at a diameter node |
IN2012CN06918A (en) * | 2010-02-12 | 2015-05-29 | Tekelec Inc | |
US9001784B2 (en) * | 2010-09-09 | 2015-04-07 | Qualcomm Incorporated | Handover of multimode user equipment between radio access technologies for reduced call setup time |
US9516102B2 (en) * | 2013-03-07 | 2016-12-06 | F5 Networks, Inc. | Server to client reverse persistence |
US9294458B2 (en) * | 2013-03-14 | 2016-03-22 | Avaya Inc. | Managing identity provider (IdP) identifiers for web real-time communications (WebRTC) interactive flows, and related methods, systems, and computer-readable media |
US9794769B2 (en) * | 2013-03-29 | 2017-10-17 | Mobileum Inc. | Enabling voice over long term evolution (VoLTE) services for non-VoLTE inbound roamers |
US9515995B2 (en) * | 2013-12-27 | 2016-12-06 | Futurewei Technologies, Inc. | Method and apparatus for network address translation and firewall traversal |
US9729454B2 (en) * | 2015-01-21 | 2017-08-08 | Oracle International Corporation | Methods, systems, and computer readable media for balancing diameter message traffic received over long-lived diameter connections |
US10129088B2 (en) * | 2015-06-17 | 2018-11-13 | Extreme Networks, Inc. | Configuration of rules in a network visibility system |
US10027577B2 (en) * | 2015-07-29 | 2018-07-17 | Oracle International Corporation | Methods, systems, and computer readable media for peer aware load distribution |
US10587586B2 (en) * | 2017-01-10 | 2020-03-10 | Mocana Corporation | System and method for a multi system trust chain |
US10277576B1 (en) * | 2017-06-29 | 2019-04-30 | Syniverse Technologies, Llc | Diameter end-to-end security with a multiway handshake |
US10200852B1 (en) * | 2017-08-24 | 2019-02-05 | Syniverse Technologies, Llc | Method and system of enabling roaming services in a data-only network to a user equipment requiring a dual attachment to packet and circuit switched networks |
-
2019
- 2019-03-14 US US16/353,581 patent/US10432583B1/en active Active
Also Published As
Publication number | Publication date |
---|---|
US10432583B1 (en) | 2019-10-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10079803B2 (en) | Peer-to-peer connection establishment using TURN | |
US10432522B2 (en) | Network packet flow controller with extended session management | |
JP6452181B2 (en) | Load balancing internet protocol security tunnel | |
US10341427B2 (en) | Forwarding policies on a virtual service network | |
CN107948076B (en) | Method and device for forwarding message | |
US7433958B2 (en) | Packet relay processing apparatus | |
JP6161803B2 (en) | Method, system, and computer program for managing a firewall cluster in a network computing environment (regional firewall clustering in a network computing environment) | |
US10027745B2 (en) | System and method for signaling and data tunneling in a peer-to-peer environment | |
Mtibaa et al. | Towards edge computing over named data networking | |
US10412159B1 (en) | Direct load balancing using a multipath protocol | |
CA2968964A1 (en) | Source ip address transparency systems and methods | |
US8683053B2 (en) | Methods and apparatus for establishing secure communications between client computing devices that use transport and security protocols | |
JP2011508550A (en) | Method, apparatus, and computer program for selective loading of security association information to a security enforcement point | |
US10462265B2 (en) | On-demand startup of offline servers and connection routing | |
US20180234506A1 (en) | System and methods for establishing virtual connections between applications in different ip networks | |
US9059968B2 (en) | Stateless transmission control protocol rendezvous solution for border gateway function | |
US10432583B1 (en) | Routing agent platform with a 3-tier architecture for diameter communication protocol in IP networks | |
US20190141009A1 (en) | Session moderator for turn-pattern tcp-packet relay with websocket instantiation | |
KR102033816B1 (en) | Assistant data transmission method | |
CN116582590A (en) | Data transmission method and device | |
CN115460213A (en) | Service processing method and device, electronic equipment and computer readable medium | |
CN115632980A (en) | Method and device for realizing routing configuration, storage medium and electronic equipment | |
CN114285771A (en) | Connection state tracking method and device of TCP connection | |
JP2012034259A (en) | Tunnel termination system, tunnel termination method, tunnel termination controller, tunnel termination control method and program therefor |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: SYNIVERSE TECHNOLOGIES, LLC, FLORIDA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YAU, EDWARD;SUN, PAUL;HANDRA, JERRY;AND OTHERS;SIGNING DATES FROM 20190319 TO 20190320;REEL/FRAME:048663/0830 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: BARCLAYS BANK PLC, AS COLLATERAL AGENT, NEW YORK Free format text: NOTICE AND CONFIRMATION OF GRANT OF SECURITY INTEREST IN PATENTS;ASSIGNOR:SYNIVERSE TECHNOLOGIES, LLC;REEL/FRAME:060072/0598 Effective date: 20220513 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |