Source: http://www.google.ca/patents/US20110200054
Timestamp: 2017-11-21 08:22:11
Document Index: 595449224

Matched Legal Cases: ['ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 600', 'ART 600', 'ART 600', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500', 'ART 500']

Patent US20110200054 - Methods, systems, and computer readable media for providing local ... - Google Patents
Methods, systems, and computer readable media for providing local application routing at a Diameter node are disclosed. One method includes receiving, at an ingress Diameter message processor associated with a Diameter signaling router (DSR), a Diameter message from a peer Diameter element. At the ingress...http://www.google.ca/patents/US20110200054?utm_source=gb-gplus-sharePatent US20110200054 - Methods, systems, and computer readable media for providing local application routing at a diameter node
Publication number US20110200054 A1
Application number US 13/026,098
Also published as CN102754409A, CN102754409B, CN102792660A, CN102792660B, CN102812671A, CN102812671B, CN102845026A, CN102845026B, CN102845027A, CN102845027B, CN102859944A, CN102859944B, CN102893556A, CN102893556B, CN104883305A, EP2507972A2, EP2507972A4, EP2534790A2, EP2534790A4, EP2534790B1, EP2534792A2, EP2534792A4, EP2534793A2, EP2534793A4, EP2534795A2, EP2534795A4, EP2534796A2, EP2534796A4, EP2534796B1, EP2534811A2, EP2534811A4, US8478828, US8483233, US8498202, US8504630, US8527598, US8532110, US8554928, US8601073, US8644324, US8792329, US8799391, US8995256, US8996636, US9088478, US20110199895, US20110199906, US20110200047, US20110200053, US20110202604, US20110202612, US20110202613, US20110202614, US20110202677, US20110202684, US20130346549, US20140074975, US20140226495, WO2011100587A2, WO2011100587A3, WO2011100594A2, WO2011100594A3, WO2011100600A2, WO2011100600A3, WO2011100606A2, WO2011100606A3, WO2011100609A2, WO2011100609A3, WO2011100610A2, WO2011100610A3, WO2011100612A2, WO2011100612A3, WO2011100615A2, WO2011100615A3, WO2011100621A2, WO2011100621A3, WO2011100626A2, WO2011100626A3, WO2011100629A2, WO2011100629A3, WO2011100630A2, WO2011100630A3
Publication number 026098, 13026098, US 2011/0200054 A1, US 2011/200054 A1, US 20110200054 A1, US 20110200054A1, US 2011200054 A1, US 2011200054A1, US-A1-20110200054, US-A1-2011200054, US2011/0200054A1, US2011/200054A1, US20110200054 A1, US20110200054A1, US2011200054 A1, US2011200054A1
Inventors Jeffrey Alan Craig, Mark Edward Kanode, Kedar Kashinath Karmarkar, Thomas M. McCann, David Michael Sprague, Mahesh Tomar, Donald E. Wallace
Original Assignee Jeffrey Alan Craig, Mark Edward Kanode, Kedar Kashinath Karmarkar, Mccann Thomas M, David Michael Sprague, Mahesh Tomar, Wallace Donald E
Patent Citations (101), Referenced by (40), Classifications (12), Legal Events (6)
US 20110200054 A1
7. The method of claim 5 wherein the Diameter peer-routing modules associated with the ingress and egress Diameter message processors share common Diameter peer-routing information.
8. The method of claim 1 wherein forwarding the Diameter message to a Diameter application identified by the application routing data for processing includes selecting one of many Diameter applications based on the availability status of the many Diameter applications.
9. The method of claim 1 wherein forwarding the Diameter message to a Diameter application identified by the application routing data for processing includes selecting one of many Diameter applications based on the congestion status of the many Diameter applications.
10. The method of claim 1 wherein forwarding the Diameter message to a Diameter application identified by the application routing data for processing includes selecting one of many Diameter applications based on the message processing capacity of the many Diameter applications.
11. A Diameter signaling router comprising:
The subject matter described herein may be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein may be implemented as a function executed by a processor. In one exemplary implementation, the subject matter described herein for providing local application routing at a Diameter node may be implemented using a non-transitory computer readable medium to having stored thereon executable instructions that when executed by the processor of a computer control the processor to perform steps. Exemplary non-transitory computer readable media suitable for implementing the subject matter described herein include chip memory devices or disk memory devices accessible by a processor, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single computing platform or may be distributed across plural computing platforms.
FIG. 1 is a flow chart illustrating a process for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 2 is a block diagram illustrating an exemplary architecture including a full stack per MP for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 4 is a block diagram illustrating an exemplary architecture including dedicated DCL/DRL and application MPs for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 6 is a block diagram illustrating an exemplary scalable, inter-MP routing DSR NE including a Diameter node per MP for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 7 is a block diagram illustrating an exemplary scalable DSR NE including functional partitioning for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 8 is a network diagram illustrating an exemplary host routing scenario for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 9 is a block diagram illustrating an exemplary client-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 10 is a block diagram illustrating an exemplary server-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 11 is a block diagram illustrating an exemplary redirect agent-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 12 is a block diagram illustrating an exemplary back-to-back application-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 13 is a block diagram illustrating an exemplary proxy agent-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 14 is a block diagram illustrating an exemplary local DSR application scenario in which service drops out for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 15 is a block diagram illustrating an exemplary routing scenario for routing message to local DSR applications for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein;
FIG. 16 is a message sequence diagram illustrating an exemplary local DSR application routing where the DRL detects internal message looping according to an embodiment of the subject matter described herein;
FIG. 17 is a message sequence diagram illustrating an exemplary local DSR application routing where DRL internal message looping is not detected according to an embodiment of the subject matter described herein;
FIG. 18 is a message sequence diagram illustrating an exemplary local DSR application routing where the local proxy application modifies an ingress message and drops out of the signaling path according to an embodiment of the subject matter described herein;
FIG. 19 is a message sequence diagram illustrating an exemplary local DSR application routing where the local proxy application does not modify the ingress message and drops out of the signaling path according to an embodiment of the subject matter described herein;
FIG. 20 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local application initiates a transaction to a remote server according to an embodiment of the subject matter described herein;
FIG. 21 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local server application receives and processes a request from a remote client according to an embodiment of the subject matter described herein;
FIG. 22 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local proxy application stays in the signaling path by creating a new session according to an embodiment of the subject matter described herein;
FIG. 23 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local proxy application stays in the signaling path without creating a new session according to an embodiment of the subject matter described herein;
FIG. 24 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local client application initiates a transaction to a remote server and a local application intercepts and drops of the signaling path according to an embodiment of the subject matter described herein;
FIG. 25 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local client application initiates a transaction to a remote server and a local application intercepts and stays in the signaling path according to an embodiment of the subject matter described herein;
FIG. 26 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local proxy application aborts the transaction according to an embodiment of the subject matter described herein;
FIG. 27 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the DSR serves as a redirect agent for a local application according to an embodiment of the subject matter described herein; and
FIG. 28 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local DSR application performs decorated NAI processing according to an embodiment of the subject matter described herein.
FIG. 1 is a flow chart for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein that includes routing Diameter messages between multiple Diameter message processors (MPs) that together constitute a DSR. Referring to FIG. 1, in step 100, a Diameter message is received, at an ingress Diameter message processor associated with the DSR, from a peer Diameter element. For example, a DSR located in a path between a Diameter client and a Diameter server may receive a Diameter Request message from the client.
A first architecture option may include where each MP supports a full Diameter stack that includes the DCL, DRL, and Application layers. A second architecture option may include a DCL that runs on dedicated MPs, Routing and Application layers can either be combined on dedicated MPs or have dedicated MPs for each layer. A third architecture option may include a Diameter stack (DCL, DRL) that runs on dedicated MPs, local Diameter applications run on separate dedicated MPs. Each of these exemplary architecture options will now be described in greater detail below with respect to FIGS. 2, 3, and 4.
FIG. 2 is a block diagram illustrating an exemplary architecture including a full stack per MP for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 2, DSR network element (NE) 200 may include ingress MP 202 for receiving Diameter messages from peers and egress MP 204 for transmitting Diameter messages to peers. Ingress MP 202 and egress MP 204 may each include a DCL, DRL, and one or more applications. For example, ingress MP 202 may include DCL 206, DRL 208, and application 210. Likewise, egress MP 204 may include DCL 212, DRL 214, and application 216. In order to communicate between ingress MP 202 and egress MP 204, DRL 208 of ingress MP 202 may be operable to communicate with DRL 214 of egress MP 204. Additionally, DRLs 208 and 214 may each be operable to communicate with DCLs 206 and 212 and applications 210 and 216, respectively.
If application processing is required, ingress DRL 208 may forward the Diameter message to a Diameter message processor hosting a local application(s). For example, DRL 208 may forward the Diameter message to an MP hosting local application 210, which processes the message and returns the message to DRL 208. It is appreciated that application distribution function may not be required.
FIG. 3 is a block diagram illustrating an exemplary architecture including dedicated DCL MPs for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. In contrast to the full stack-per MP embodiment shown in FIG. 2, the embodiment shown in FIG. 3 includes dedicated DCL MPs. Referring to FIG. 3, DSR NE 200 may include DCL-MP 300 for receiving Diameter messages from peers and DCL-MP 308 for transmitting Diameter messages to peers. Similarly, DSR NE 200 may include DRL-MP 302 and DRL-MP 306 for receiving Diameter messages from peers and for transmitting Diameter messages to peers. In contrast to a full stack-per MP embodiment (FIG. 2), application-MP 304 may be associated with DRL-MP 302 and may not have a corollary associated with DRL-MP 306. Like FIG. 2, DRL-MPs 302 and 306 may each be operable to communicate with one another.
Therefore, in an exemplary Diameter message routing scenario analogous to the one described above with respect to FIG. 2, ingress Diameter messages may be received by DCL-MP 300, which may distribute the Diameter message (e.g., Request messages) to DRL-MP 302 based on various factors including, but not limited to, the availability, transactions per second (TPS) capacity and congestion status of DRL-MP 302 as compared with other DRL-MPs (not shown in their entirety).
Ingress DRL-MP 302 may then select a destination peer for the message and ingress DRL-MP 302 may forward the message to egress DRL-MP 306. Egress DRL-MP 306 may then forward the message to egress DCL-MP 308 (highest degree on inter-MP communication) for delivery to peer N+1 220 selected by DRL-MP 302.
FIG. 4 is a diagram illustrating an exemplary architecture including dedicated DCL/DRL and application MPs for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. It may be appreciated that FIG. 4 represents a hybrid approach between the full stack per MP of FIG. 2 and the dedicated DCL/DRL/application-MPs of FIG. 3. Referring to FIG. 4, in an exemplary Diameter message routing scenario, peer N-1 218 may send a Diameter message to DSR NE 200. The Diameter message may be received by DCL 206 of ingress MP 202. Ingress messages may be processed completely on ingress MP 202 up through the selection of a destination peer for the Diameter message by DRL 208. DCL 206 may then pass the Diameter message to DRL 208.
FIG. 5 is a block diagram illustrating an exemplary high level message routing flow for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 5, peer N-1 218 may send a Diameter request message to DSR 200. DSR 200 may consult ART 500 in order to determine whether processing of the message by a Diameter application is required. ART 500 may be searched when an ingress message is received from a peer. If the message content matches an ART rule, the message is forwarded to the application for processing. This continues iteratively until no additional rule matches are found. For example, ART 500 may forward the message to application-1 210 for processing and, after the message is returned to ART 500, the message may then be forwarded to application-2 216 for processing.
After local application processing is completed, ART 500 may forward the message to PRT 502. Peer Routing Table (PRT) 502 may be searched after ART 500 searching is completed such that if the message content (after application processing updates) matches a PRT 502 rule, the message may be routed to a Diameter peer as defined by a Route List in route list table 504 associated with the rule. Thus, the message may be sent to peer N+1 220 after consulting route list table 504.
FIG. 6 is a block diagram illustrating an exemplary scalable, inter-MP routing DSR NE including a Diameter node per MP for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. A Diameter node per MP design may have several disadvantages from a customer point of view. For example, separate ART, PRT and Route List tables must be configured on each DSR MP. Additionally, the full-mesh backbone between the DSR MPs must be configured and the overhead of DRL routing rules must be applied twice each time a message is routed between two DSR MPs as shown below. As a result, it is desirable to reduce or eliminate these disadvantages.
According to one embodiment, an improvement to “N” independent DSR nodes is to share the DRL tables between DSR MPs, thus treating the DSR NE as a single Diameter “Node” from a routing perspective. In such an embodiment, the ART, PRT, Route List, Route Group, Route and Peer tables may be common to all DSR MPs in the DSR NE. A new “DSR NE” Table may then be created to serve as the source for auto-configuration of full-mesh SCTP connections amongst the MPs which are part of an DSR NE. Additionally, it may be desirable to support multiple DSR NEs at the same site.
Referring to FIG. 6, ingress MP 200 may become DSR MP (N) 200 and egress MP 204 may become DSR MP (N+1) 204. Peer N-1 218 may send a Diameter message to DSR MP (N) 200, where it may be processed by ART 500. ART 500 may determine whether local application processing is required and, if so, may forward the Diameter message to application 210. After being returned to ART 500, the Diameter message may be forwarded to PRT 502 and then to route list table 504.
When the message is received by DSR MP (N+1) 204, it may be processed by ART 600. ART 600 may determine whether local application processing is required and, if so, may forward the Diameter message to application 216. After being returned to ART 600, the Diameter message may be forwarded to PRT 602 and then forwarded to route list table 604.
FIG. 7 is a block diagram illustrating an exemplary scalable DSR NE including functional partitioning for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 7, it may be appreciated that message delivery step 620 of route list processing 700 may be associated with logical egress MP 204, while the remaining functionality may be associated with logical ingress MP 202. Specifically, ART 500, local application 210, PRT 502, and the selection of a route group step 520 and the selection of a route from the route group step 610 of route list processing 700 may be associated with logical ingress MP 202.
DSR Request-Message Processing & Routing
DRL routing rules may consist of a pre-defined set of columns in a table, each column associated with message parameter, that the user can define a criteria for (e.g., “equals value “X”, parameter's value or existence is “don't care”, etc. If the message matches more than one routing rule, the highest priority routing rule is selected and the “action” assigned to the routing rule by the operator will be invoked. Example “actions” may include routing to local DSR application (ART) or peer (PRT) and sending an answer response message.
Each routing table may support the following basic Request message parameters: Destination-Realm AVP, Destination-Host AVP, and Application ID (in header). In addition to the Request message parameters described above, the subject matter described herein may also support the following Request message parameters: Origin-Realm AVP, Origin-Host AVP, User-Name AVP, and Command-Code (in header).
Routing Rules—Parameter Values
For each message parameter in a message routing rule, the operator should be able to specify a value (e.g., exact, prefix, postfix), whether the parameter exists or whether it doesn't matter (don't care). The following should be supported. It is appreciated that many message parameters are of type integer or string, including: decimal value (exact match), character string (exact match), character string (prefix match), character string (postfix match), “no AVP instances present”, “at least one AVP instance present” (regardless of its value), and “don't care” (ignore its presence and value). If the parameter is located in the Diameter message header, then this represents the actual field value. If the parameter is an AVP, then this represents the “Data” field of the AVP.
Routing Tables—Searching
Desti- Appli- Desti-
nation cation nation Route List
Rule# Realm ID Host Name Action Priority
1 tklc.com 88 www.tklc.com TKLC- Route 1
Webserver to Peer
2 tklc.com 88 don't care TKLC- Route 2
Realm to Peer
3 tklc.com don't don't care TKLC- Route 99
care Default to Peer
In a first exemplary scenario, a message may be received including the following parameters: Destination-Realm=tklc.com, Application-ID=88, and Destination-Host=www.tklc.com. Referring to Table 1, rules 1, 2, and 3 match, but rule 1 would be selected because it has the highest priority.
FIG. 8 is a network diagram illustrating an exemplary host routing scenario for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. In one embodiment, one use of multiple routes to a directed connected host includes a Route List configuration with a single, high-priority route associated with the direct connection to the host and one or more lower priority routes through adjacent Relay Agents. Active routes may be used for routing messages to the Host. Standby routes may be used if the Active routes fail.
DRL may support the following types of local DSR applications. First, DRL may support an addressable Diameter Node endpoint that either originates or terminates a Diameter session (e.g., Diameter Client, Server, or Translation Agent). DRL may also support a Diameter relay agent that may or may not be an addressable Diameter node which intercepts certain types of messages and sends an Answer response to the peer containing new destination routing information. DRL may support a back-to-back application that is an addressable Diameter node which terminates a Diameter session from one node, initiates a new Session on behalf of the requestor, and interworks the sessions between the two nodes (e.g., AAAH Server). DRL may support an application that is NOT an addressable Diameter node but wants to insert itself in the end-to-end transaction signaling flow (Request/Answer) and may add or modify AVPs in the message (e.g., Diameter Proxy Agent). DRL may support an application that is NOT an addressable Diameter node, wants to intercept certain messages and optionally modify the message that, for example, affects message routing, but does NOT want to remain in the end-to-end signaling flow (e.g., Tekelec DSR value-add service).
FIG. 9 is a block diagram illustrating an exemplary client-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 9, client 900 may send a Diameter Request message to DRL 208 which is received by ART 500. ART 500 is used to determine whether processing of the Diameter message by a Diameter application is required. In response to determining that Diameter application processing is required, the Diameter message is forwarded to Peer routing table 502 and then to route list table 504. Based on the result of lookups performed in tables 500-504, peer 220 is identified and the Diameter message is forwarded. After processing the Request, peer 220 returns an Answer message to DRL answer processing 902, which in turn sends the Answer message to client 900.
FIG. 10 is a block diagram illustrating an exemplary server-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 10, peer 218 may send a Diameter Request to DRL 208 which is received by ART 500. ART 500 is used to determine whether processing of the Diameter message by a Diameter application is required. In response to determining that Diameter application processing is required, the Diameter Request message is forwarded to server 1000. After processing the Request, server 1000 generates and returns a Diameter Answer message to DRL answer processing 902, which in turn sends the Answer message to peer 218.
FIG. 11 is a block diagram illustrating an exemplary redirect agent-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 11, peer 218 may send a Diameter Request to DRL 208 which is received by ART 500. ART 500 is used to determine whether processing of the Diameter message by a Diameter application is required. In response to determining that Diameter application processing is required, the Diameter Request message is forwarded to redirect agent 1100. After processing the Request, redirect agent 1100 generates and returns a Diameter Answer message to DRL answer processing 902, which in turn sends the Answer message to peer 218.
FIG. 12 is a block diagram illustrating an exemplary back-to-back application-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 12, peer 218 may send a Diameter Request message for session=foo to DRL 208 which is received by ART 500. ART 500 is used to determine whether processing of the Diameter message by a Diameter application is required. In response to determining that Diameter application processing is required, the Diameter message is forwarded to back-to-back application 1200 for processing. After processing the Request for session=foo, back-to-back application 1200 returns a Request for session=bar to ART 500. ART 500 then forwards the Request for session=bar to peer routing table 502 and then to route list table 504. Based on the result of lookups performed in tables 500-504, peer 220 is identified and the Diameter message is forwarded. After processing the Request message for session=bar, peer 220 returns an Answer message for session=bar to DRL answer processing 902, which in turn sends the Answer message back to back-to-back application 1200. Back-to-back application 1200 processes the message and returns an Answer message for session=foo to DRL answer processing 902, which in turn sends the Answer message for session=foo to peer 218 corresponding to its Request for session=foo.
FIG. 13 is a block diagram illustrating an exemplary proxy agent-based local DSR application for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 13, peer 218 may send a Diameter Request message for session=foo to DRL 208 which is received by ART 500. ART 500 is used to determine whether processing of the Diameter message by a Diameter application is required. In response to determining that Diameter application processing is required, the Diameter message is forwarded to proxy agent 1300 for processing. After processing the Request for session=foo, proxy agent 1300 returns a Request for session=foo to ART 500. ART 500 then forwards the Request for session=foo to peer routing table 502 and then to route list table 504. Based on the result of lookups performed in tables 500-504, peer 220 is identified and the Diameter message is forwarded. After processing the Request message for session=foo, peer 220 returns an Answer message for session=foo to DRL answer processing 902, which in turn sends the Answer message back to proxy agent 1300. Proxy agent 1300 processes the message and returns an Answer message for session=foo to DRL answer processing 902, which in turn sends the Answer message for session=foo to peer 218 corresponding to its Request for session=foo.
FIG. 14 is a block diagram illustrating an exemplary local DSR application scenario in which service drops out for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. Referring to FIG. 14, peer 218 may send a Diameter Request message for session=foo to DRL 208 which is received by ART 500. ART 500 is used to determine whether processing of the Diameter message by a Diameter application is required. In response to determining that Diameter application processing is required, the Diameter message is forwarded to DSR service 1400 for processing. After processing the Request for session=foo, DSR service 1400 sends a Diameter Answer message for session=foo to DRL answer processing 902, which in turn sends another Request message for session=foo to ART 500. ART 500 then forwards the Request for session=foo to peer routing table 502 and then to route list table 504. Based on the result of lookups performed in tables 500-504, peer 220 is identified and the Diameter message is forwarded. After processing the Request message for session=foo, peer 220 returns an Answer message for session=foo to DRL answer processing 902, which in turn sends the Answer message back to peer 218 corresponding to its Request for session=foo.
FIG. 15 is a block diagram illustrating an exemplary routing scenario for routing message to local DSR applications for providing local application routing at a Diameter node according to an embodiment of the subject matter described herein. In order to support a variety of local applications serving as different types Diameter nodes (client, proxy, etc), DRL should treat local applications similar to peers from a message routing perspective.
It is appreciated that “pending transaction” queues may be supported for backwards routing of Answer responses. For example, when a local client or server application sends a Request message, DRL may need to route the Answer response back to that application. When DRL routes a Request message to a client of server application, DRL may need to route the Answer response from the local application back to the peer from which the Request was received. It may be appreciated that a Request message sent to a local application may or may not be saved in a “pending transaction” queue and that hop-by-hop IDs may be used for correlating messages exchanged between DRL and local applications without departing from the scope of the subject matter described herein.
In order to support the control of local application sequencing, the “origin application ID” will be used to search the ART. Each time the ART is searched, the “origin application ID” will be set to local application ID from which the message was received. When the initial message is received from a peer, DRL will set the “origin local application ID” to a default value indicating that the source of the message was a peer (e.g., “NETWORK” or “DRL”). For example, if the operator wanted to invoke four local DSR applications 21, 10, 33, and 5, in that priority order, whenever a message was received from a peer with Destination-Realm=“att.com” and Application ID=55, then the following ART rules would be configured.
In order to prevent inter-local application message processing loops, DRL will utilize a DSR-specific Internal-Route-Record AVP, similar to the Route-Record AVP used to detect internal message looping. Each time DRL invokes a local application for an end-to-end Diameter transaction, it will add an Internal-Route-Record AVP containing the identity of the local application which previously processed the message. Each time DRL searches the ART and finds one or more rules which match, it must validate that the Destination-Application-ID of the highest rule does not match any of the Internal-Route-Record AVP values (indication that the application has already been invoked for this end-to-end transaction). If a message loop is detected, DRL will abandon routing for this message and send a Diameter_UNABLE_TO_DELIVER Answer response to the peer and assert a local OAM alarm or event to notify the operator of a potential ART configuration problem. It may be appreciated, however, that when DRL completes application routing, DRL may delete all Internal-Route-Record AVPs from the message prior to searching the PRT.
FIG. 16 is a message sequence diagram illustrating an exemplary local DSR application routing where the DRL detects internal message looping according to an embodiment of the subject matter described herein. In the use case shown in FIG. 16, Appl-2 wants to stay in the signaling path but is not creating a new Session. Referring to FIG. 16, DRL 308 may be located between local application-1 1600 and local application-2 1602.
At step 1604, a Request message may be sent from local application-1 1600 to DRL 308 indicating Session-ID=888, Hop-by-Hop=100, and End-to-End=999.
At step 1606, DRL 308 may receive a new transaction and search its ART using Origin-Appl-Name=Appl-1. The result of the search may include finding a match for Appl-2. DRL 308 may then initiate a new transaction to Appl-2 and map (Appl-1, Hop=100) to (Appl-2, Hop=200). DRL 308 may save Appl-1 and Appl-2 in “List of local applications invoked”.
At step 1608, a Request message may be sent from DRL 308 to local application-2 1602 indicating (Session-ID=888, Hop-by-Hop=200, End-to-End=999, “Message from Appl-1”, Internal-Route-Record=Appl-1).
At step 1610, local application-2 1602 may want to stay in signaling path. Therefore, local application-2 1602 may apply any changes to the message received in step 1608 and initiate a new peer-to-peer transaction “300” to DRL 308.
At step 1612, local application-2 1602 may send a Request message to DRL 308 indicating (Session-ID=888, Hop-by-Hop=300, End-to-End=999, “Message from Appl-2”, Internal-Route-Record=Appl-1).
Because local application looping is not allowed, DRL 308 may send an Answer response with Result-Code set to “Diameter_LOOP_DETECTED”. For example, at step 1616, DRL 308 may send an Answer message to local application-2 1602 indicating (Session-ID=888, Hop-by-Hop=300, End-to-End=999, Result-Code=Diameter_LOOP_DETECTED).
At step 1618, local application-2 1602 may send an Answer message to DRL 308 indicating (Session-ID=888, Hop-by-Hop=200, End-to-End=999, Result-Code=Diameter_LOOP_DETECTED).
At step 1620, DRL 308 may correlate (Appl-2, Hop=200) to (Appl-1, Hop=100). It may be appreciated that this mapping was also performed in step 1606 above.
At step 1622, DRL 308 may send an Answer message to local application-1 1600 indicating (Session-ID=888, Hop-by-Hop=100, End-to-End=999, Result-Code=Diameter_LOOP_DETECTED).
FIG. 17 is a message sequence diagram illustrating an exemplary local DSR application routing where DRL internal message looping is not detected according to an embodiment of the subject matter described herein. In the use case shown in FIG. 17, local application-2 1602 may include a back-to-back proxy that creates a new session. Referring to FIG. 17, in addition to local application-1 1600, local application-2 1602, and DRL 308, a server 1700 is shown.
At step 1704, DRL 308 may receive a new transaction and search its ART using Origin-Appl-Name=Appl-1. The result of the search may include finding a match for Appl-2. DRL 308 may then initiate a new transaction to Appl-2 1602 with Internal-Route-Record=Appl-1 and map (Appl-1, Hop=100) to (Appl-2, Hop=200).
At step 1706, DRL 308 may send a Request message to local application-2 1602 indicating (Session-ID=888, Hop-by-Hop=200, End-to-End=999, “Message from Appl-1”, Internal-Route-Record=Appl-1).
At step 1708, Appl-2 1602 may be a back-to-back proxy agent which interworks between two sessions (e.g., session 888 and session 222). When Session-ID=888 is received from Appl-1 1600, Appl-2 1602 may open a new Session-ID=222 and initiate a new end-to-end transaction “300” to DRL 308 which does not forward the Internal-Route-Record AVPs.
At step 1710, session 222 may begin when local application-2 1602 sends a Request message to DRL 308 indicating (Session-ID=222, Hop-by-Hop=300, End-to-End=1, “Message from Appl-2”).
At step 1714, DRL 308 may send a Request message to local application-1 1600 indicating (Session-ID=222, Hop-by-Hop=400, End-to-End=1, “Message from Appl-2”, Internal-Route-Record=Appl-2).
At step 1716, local application-1 1600 may send a Request message to DRL 308 indicating (Session-ID=222, Hop-by-Hop=500, End-to-End=1, “Message from Appl-1”, Internal-Route-Record=Appl-2).
At step 1718, DRL 308 may send a Request message to server1 1700 indicating (Session-ID=222, Hop-by-Hop=600, End-to-End=1, “Message from Appl-1”).
In order for DRL 308 to support the ability for local applications to modify a message but not remain in the signaling path for the remainder of that transaction or session, the following DSR-specific Answer message enhancements may be used. First, the ability to return an “updated message” in the Answer response. Second, the ability for an local application to notify DRL that it should continue routing the original Request message rather than propagating the Answer response to a peer.
When a local DSR application wants to notify DRL 308 that it has completed application processing and that Request message routing should continue, the local DSR application must set the Result-Code in the Answer response to the DSR application-specific value “Continue”. It may be appreciated that this contrasts with normal DRL processing which would propagate the Answer to the peer).
If the local application has modified the message, it may return the updated message in a DSR application-specific AVP called “Updated-Message”. If the Updated-Message AVP is present, then DRL 308 will continue local application routing with the new message. If the Updated-Message AVP is not present, then DRL 308 may continue local application routing with the original message. It is further appreciated that the Updated-Message AVP may only be required if DRL 308 and the local application cannot access the same shared memory space. Due to the size of Diameter messages, it may be more efficient to modify messages in place rather than copying them between DRL and local applications.
FIG. 18 is a message sequence diagram illustrating an exemplary local DSR application routing where the local proxy application modifies an ingress message and drops out of the signaling path according to an embodiment of the subject matter described herein. Referring to FIG. 18, at step 1802, client1 1800 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, End-to-End=999, Dest-Realm=att.com, User-Name=IMSI).
At step 1804, DRL 308 may search its ART using Origin-Appl-Name=“Network”._find match_LAPR Action=“Route to Local DSR Appl-1”. DRL 308 may then create a new internal transaction “200” for Appl-1 1600 and map (Client1, Hop=100) to (Appl-1, Hop=200).
At step 1806, DRL 308 may send a Request message to local application-1 1600 indicating (Hop-by-Hop=200, End-to-End=999, “Message from Client1”).
At step 1808, local application-1 1600 may send an Answer message to DRL 308 indicating (Hop-by-Hop=200, End-to-End=999, Result-Code=Continue, Updated-Message=“Message from Appl-1”).
At step 1810, the Answer response from Appl-1 1600 may include the application-specific Result-Code=Continue (i.e., Appl-1 is requesting that Request message processing should continue). Therefore, DRL 308 may remove the (Client1, Hop=100) to (Appl-1, Hop=200) mapping (performed in step 1804 above) and re-search its ART with Origin-Appl-Name=Appl-1. Finding no additional matches, DRL 308 may then search its PRT with the message received from Appl-1 1600 and find a rule with Route List-5 which resolves to Route-2 (Server1 1700). DRL 308 may then create a (Client1, Hop=100) to (Server1, Hop=300) mapping.
At step 1812, DRL 308 may send a Request message to server1 1700 indicating (Hop-by-Hop=300, End-to-End=999, “Message from Appl-1”).
At step 1814, server1 1700 may send an Answer message to DRL 308 indicating (Hop-by-Hop=300, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 1816, DRL 308 may correlate (Server1, Hop=300) to (Client1, Hop=100). It is appreciated that this mapping was performed in step 1810 above.
At step 1818, DRL 308 may send an Answer message to client1 1800 indicating (Hop-by-Hop=100, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
FIG. 19 is a message sequence diagram illustrating an exemplary local DSR application routing where the local proxy application does not modify the ingress message and drops out of the signaling path according to an embodiment of the subject matter described herein.
At step 1900, client1 1800 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, End-to-End=999, Dest-Realm=att.com, User-Name=IMSI).
At step 1902, DRL 308 may search its ART with Origin-Appl-Name=“Network” and finds LAPR Action=“Route to Local DSR Appl-1”. It may create a new internal transaction “200” for Appl-1 1600 and map (Client1, Hop=100) to (Appl-1, Hop=200).
At step 1904, DRL 308 may send a Request message to local application-1 1600 indicating (Hop-by-Hop=200, End-to-End=999, “Message from Client1”).
At step 1906, local application-1 1600 may return an Answer message to DRL 308 indicating (Hop-by-Hop=200, End-to-End=999, Result-Code=Continue).
At step 1908, it is appreciated that Answer response from Appl-1 has application-specific Result-Code=Continue (i.e., Appl-1 is requesting that Request message processing should continue). Therefore, DRL 208 may remove the (Client1, Hop=100) to (Appl-1, Hop=200) mapping performed in step 1902 above and re-search its ART with Origin-Appl-Name=Appl-1. Finding no additional matches, DRL 208 may then search its PRT with the message received from Client-1 1800 and find a rule with Route List-5 which resolves to Route-2 (i.e., Server1 1700). DRL 208 may then create (Client1, Hop=100) to (Server1, Hop=300) mapping.
At step 1910, DRL 308 may send a Request message to server1 1700 indicating (Hop-by-Hop=300, End-to-End=999, “Message from Client-1”).
At step 1912, server1 1700 may return an Answer message to DRL 308 indicating (Hop-by-Hop=300, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 1914, DRL 308 may correlate (Server1, Hop=300) to (Client1, Hop=100). It is appreciated that this mapping was performed in step 1908 above.
At step 1916, DRL 308 may send an Answer message to client 1 1800 indicating (Hop-by-Hop=100, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
Application Routing Table—Contents
Rule Name—operator-provided name for rule identification.
Rule Priority—if a table query finds multiple matches, then the entry with the highest (lowest value) priority will be selected.
(M) Destination-Realm—similar to Diameter Realm Routing Table, core data type: OctetString
(M) Application ID—similar to Diameter Realm Routing Table, 32-bit value
(M) Destination-Host—similar to “Host Identity” in Diameter Peer Table, core data type: OctetString
(D) Origin-Realm—identifies the realm from which the message was originated. This is typically a Client node. This is currently categorized as “D”esirable but not mandatory for supporting the basic routing capabilities, core data type: OctetString
(D) Origin-Host—identifies the Host from which the message was originated
(D) User-Name—identifies the user for which this service is being invoked, core data type: OctetString
(D) Command-Code—identifies the request message type. Any value should be supported to support adding application-specific command-codes in the future, 24-bit value
Rule Action—defines the action to perform when this rule is invoked. Actions supported:
Route to Local DSR Application—the message will be routed to the local DSR application identified by the rule's Destination-Application-ID field (see below).
Send Answer Response—an Answer response will be sent using the rule's Result-Code field (see below) and no further message processing will occur.
Destination-Application-ID—the message will be routed to this local DSR Application ID when the Action is set to “Route to Local DSR Application”
Result Code—the Result-Code AVP value to use when the “Action” is set to “Send Answer Response”. Default value is 3002 “Diameter_UNABLE_TO_DELIVER”
FIG. 20 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local application initiates a transaction to a remote server according to an embodiment of the subject matter described herein. Referring to FIG. 20, at step 2000, local application-1 1600 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, End-to-End=999, Dest-Realm=att.com, Application ID=455).
At step 2002, DRL 308 may receive a new transaction and search its ART using Origin-Appl-Name=Appl-1. Finding no matches (i.e., no other local application processing required), DRL 308 may then search its PRT and find a rule for Route List-5 which resolves to Route-2 (Server1). DRL 308 may then map (Appl-1, Hop=100) to (Server1, Hop=200).
At step 2004, DRL 308 may send a Request message to server1 1700 indicating (Hop-by-Hop=200, End-to-End=999, Application ID=455, Dest-Realm=att.com).
At step 2006, server1 1700 may return an Answer message to DRL 308 indicating (Hop-by-Hop=200, End-to-End=999, Application ID=455, Result-Code=DIAMETER_SUCCESS).
At step 2008, DRL 308 may correlate (Server1, Hop=200) to (Appl-1, Hop=100). It may be appreciated that this mapping was done in step 2002 above.
At step 2010, DRL 308 may send an Answer message to local application-1 1600 indicating (Hop-by-Hop=100, End-to-End=999, Application ID=455, Result-Code=DIAMETER_SUCCESS).
FIG. 21 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local server application receives and processes a request from a remote client according to an embodiment of the subject matter described herein. Referring to FIG. 22, at step 2100, client1 1800 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, End-to-End=999, Dest-Realm=att.com, User-Name=IMSI).
At step 2102, DRL 308 may search its ART using Origin-Appl-ID=“Network” and find rule with Action=“Route to Local DSR” and Destination-Appl-ID=1. DRL 308 may then create a new internal transaction “200” for Appl-1 and map (Client1, Hop=100) to (Appl-1, Hop=200).
At step 2104, DRL 308 may send a Request message to local application-1 1600 indicating (Hop-by-Hop=200, End-to-End=999, “Message from Client1”).
At step 2106, local application-1 1600 may return an Answer message indicating (Hop-by-Hop=200, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 2108, DRL 308 may correlate (Appl-1, Hop=200) to (Client1, Hop=100). It may be appreciated that this mapping was done in step 2102 above.
At step 2110, DRL 308 may send an Answer message to client1 1800 indicating (Hop-by-Hop=100, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
FIG. 22 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local proxy application stays in the signaling path by creating a new session according to an embodiment of the subject matter described herein. In the use case shown in FIG. 22, Appl-1 1600 is a back-to-back Proxy Agent which creates a new Session. Most likely the Destination-Host was addressed to the DSR Application.
At step 2200, client1 1800 may send a Request message to DRL 308 indicating (Session-ID=222, End-to-End=999, Hop-by-Hop=100, “Message form Client1”).
At step 2202, DRL 308 may search its ART using Origin-Appl-ID=“Network” and find a rule with Action=“Route to Local DSR” and Destination-Appl-ID=1. DRL 308 may then create a new internal transaction “200” for Appl-1 and map (Client1, Hop=100) to (Appl-1, Hop=200).
At step 2204, DRL 308 may send a Request message to local application-1 1600 indicating (Session-ID=222, Hop-by-Hop=200, End-to-End=999, “Message from Client1”).
At step 2206, Appl-1 1600 may be a back-to-back Proxy Agent which interworks between two sessions. When Session-ID=888 is received, Appl-1 1600 may open a new Session-ID=222 and initiate a new end-to-end transaction “1” to DRL 308.
At step 2208, local application-1 1600 may send a Request message to DRL 308 indicating (Session-ID=888, Hop-by-Hop=300, End-to-End=1, “Message from Appl-1”).
At step 2210, DRL 308 may receive a new transaction and search its ART using Origin-Appl-Name=Appl-1, but find no matches. DRL 308 may then search its PRT and find a rule for Route List-5 which resolves to Route-2 (Server1). DRL 308 may map (Appl-1, Hop=300) to (Server1, Hop=400).
At step 2212, DRL 308 may send a Request message to server1 1700 indicating (Session-ID=888, Hop-by-Hop=400, End-to-End=1, “Message from Appl-1”).
At step 2214, server1 1700 may return an Answer message to DRL 308 indicating (Session-ID=888, Hop-by-Hop=400, End-to-End=1, Result-Code=DIAMETER_SUCCESS).
At step 2216, DRL 308 may correlate (Server1, Hop=400) to (Appl1, Hop=300). It is appreciated that this mapping was done in step 2210 above.
At step 2218, DRL 308 may send an Answer message to local application 1600 indicating (Session-ID=888, Hop-by-Hop=300, End-to-End=1, Result-Code=DIAMETER_SUCCESS).
At step 2220, local application-1 1600 may return an Answer message to DRL 308 indicating (Session-ID=222, Hop-by-Hop=200, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 2222, DRL 308 may correlate (Appl-1, Hop=200) to (Client1, Hop=100). It may be appreciated that this mapping was done in step 2202 above.
At step 2224, DRL 308 may send an Answer message to client1 1800 indicating (Session-ID=888, Hop-by-Hop=100, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
FIG. 23 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local proxy application stays in the signaling path without creating a new session according to an embodiment of the subject matter described herein. In the use case shown in FIG. 23, Appl-1 1600 may be a Proxy Agent which does not create a new Session because it is merely tweaking the messages for end-to-end transactions.
At step 2300, client1 1800 may send a Request message to DRL 308 indicating (Session-ID=999, Hop-by-Hop=100, “Message form Client1”).
At step 2302, DRL 308 may search its ART using Origin-Appl-ID=“Network” and find a rule with Action=“Route to Local DSR” and Destination-Appl-ID=1. DRL 308 may then create a new internal transaction “200” for Appl-1 and map (Client1, Hop=100) to (Appl-1, Hop=200).
At step 2304, DRL 308 may send a Request message to local application-1 1600 indicating (Session-ID=999, Hop-by-Hop=200, End-to-End=999, “Message from Client1”).
At step 2306, Appl-1 1600 may want to stay in signaling path so Appl-1 1600 may apply any changes to the message and initiate a new transaction “300” to DRL 308 without creating a new Session.
At step 2308, local application-1 1600 may send a Request message to DRL 308 indicating (Session-ID=999, Hop-by-Hop=300, End-to-End=999, “Message from Appl-1”).
At step 2310, DRL 308 may receive new transaction, search its ART using Origin-Appl-Name=Appl-1, and find no matches. DRL 308 may then search its PRT and find a match for Route List-5 which resolves to Route-2 (Server1). DRL 308 may map (Appl-1, Hop=300) to (Server1, Hop=400).
At step 2312, DRL 308 may send a Request message to server1 1700 indicating (Session-10=999, Hop-by-Hop=400, End-to-End=999, “Message from Appl-1”).
At step 2314, server1 1700 may return an Answer message to DRL 308 indicating (Session-ID=999, Hop-by-Hop=400, End-to-End, Result-Code=DIAMETER_SUCCESS).
At step 2316, DRL 308 may correlate (Server1, Hop=400) to (Appl1, Hop=300). It may be appreciated that this mapping was done in step 2310 above.
At step 2318, DRL 308 may send an Answer message to local application-1 1600 indicating (Session-ID=999, Hop-by-Hop=300, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 2320, local application-1 1600 may return an Answer message to DRL 308 indicating (Session-ID=999, Hop-by-Hop=200, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 2322, DRL 308 may correlate (Appl-1, Hop=200) to (Client1, Hop=100). It may be appreciated that this mapping was done in step 2302 above.
At step 2324, DRL 308 may send an Answer message to client1 1800 indicating (Session-ID=999, Hop-by-Hop=100, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
FIG. 24 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local client application initiates a transaction to a remote server and a local application intercepts and drops of the signaling path according to an embodiment of the subject matter described herein. Referring to FIG. 24, at step 2400, local application-1 1600 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, End-to-End=999, Dest-Realm=att.com, Application ID=455).
At step 2402, DRL 308 may receive a new transaction and search its ART using Origin-Appl-Name=Appl-1 to find a rule with Action=“Route to Local DSR” and Destination-Appl-ID=2. DRL 308 may then initiate a new transaction to Appl-2 and map (Appl-1, Hop=100) to (Appl-2, Hop=200).
At step 2404, DRL 308 may send a Request message to local application-2 1602 indicating (Hop-by-Hop=200, End-to-End=999, “Message from Appl-1”).
At step 2406, local application-2 1602 may return an Answer message to DRL 308 indicating (Hop-by-Hop=200, End-to-End=999, Result-Code=Continue, [“Message from Appl-2”]).
At step 2408, the Answer response from Appl-1 1600 may have the application-specific Result-Code=Continue (i.e., Appl-1 is requesting that Request message processing should continue). Therefore, DRL 308 may remove (Appl-1, Hop=100) to (Appl-2, Hop=200) mapping (done in step 2402 above) and re-search its ART using Origin-Appl-Name=Appl-2 to find no additional matches. DRL 308 may then search its PRT and find RRR with Route List-5 which resolves to Route-2 (Server1). DRL 308 may then create (Client1, Hop=100) to (Server1, Hop=300) mapping.
At step 2410, DRL 308 may send a Request message to server1 1700 indicating (Hop-by-Hop=300, End-to-End=999, “Message from Appl-2”).
At step 2412, server1 1700 may return an Answer message to DRL 308 indicating (Hop-by-Hop=300, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 2414, DRL 308 may correlate (Server1, Hop=300) to (Appl-1, Hop=100). It may be appreciated that this mapping was done in step 2408 above.
At step 2416, DRL 308 may send an Answer message to local application-1 1600 indicating (Hop-by-Hop=100, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
FIG. 25 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local client application initiates a transaction to a remote server and a local application intercepts and stays in the signaling path according to an embodiment of the subject matter described herein. Referring to FIG. 25, at step 2500, local application-1 1600 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, End-to-End=999, Dest-Realm=att.com, Application ID=455).
At step 2502, DRL 308 may receive a new transaction, search its ART with Origin-Appl-Name=Appl-1 and find a rule with Action=“Route to Local DSR” and Destination-Appl-ID=2. DRL 308 may then initiate a new transaction to Appl-2 and map (Appl-1, Hop=100) to (Appl-2, Hop=200).
At step 2504, DRL 308 may send a Request message to local application-2 1602 indicating (Hop-by-Hop=200, End-to-End=999, “Message from Appl-1”).
At step 2506, Appl-2 1602 may want to stay in signaling path, therefore application-2 1602 may apply any changes to message and initiate new transaction “200” to DRL 308 (Appl-2 1602 maintains state information associated with the Diameter session).
At step 2508, local application-2 1602 may send a Request message to DRL 308 indicating (Hop-by-Hop=300, End-to-End=999, “Message from Appl-2”).
At step 2510, DRL 308 may receive a new transaction, search its ART using Origin-Appl-Name=Appl-2 and find no matches. DRL 308 may then search its PRT and find a match for Route List-5 which resolves to Route-2 (Server1). DRL 308 may then map (Appl-2, Hop=300) to (Server1, Hop=400).
At step 2512, DRL 308 may send a Request message to server1 1700 indicating (Hop-by-Hop=400, End-to-End=999, “Message from Appl-2”).
At step 2514, server1 1700 may return an Answer message to DRL 308 indicating (Hop-by-Hop=400, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 2516, DRL 308 may correlate (Server1, Hop=400) to (Appl-2, Hop=300). It may be appreciated that this mapping was done in step 2510 above.
At step 2518, DRL 308 may send an Answer message to local application-2 1602 indicating (Hop-by-Hop=300, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 2520, local application-2 1602 may return an Answer message to DRL 308 indicating (Hop-by-Hop=200, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
At step 2522, DRL 308 may correlate (Appl-2, Hop=200) to (Appl-1, Hop=100). It may be appreciated that this mapping was done in step 2502 above.
At step 2524, DRL 308 may send an Answer message to local application-1 1600 indicating (Hop-by-Hop=100, End-to-End=999, Result-Code=DIAMETER_SUCCESS).
FIG. 26 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local proxy application aborts the transaction according to an embodiment of the subject matter described herein. Referring to FIG. 24, at step 2600, client1 1800 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, End-to-End=999, Dest-Realm=att.com, User-Name=IMSI).
At step 2602, DRL 308 may search its ART using Origin-Appl-ID=“Network” and find rule with Action=“Route to Local DSR” and Destination-Appl-ID=1. DRL 308 may then create a new internal transaction “200” for Appl-1 and map (Client1, Hop=100) to (Appl-1, Hop=200).
At step 2604, DRL 308 may send a Request message to local application-1 1600 indicating (Hop-by-Hop=200, End-to-End=999, “Message from Client1”).
At step 2608, local application-1 1600 may return an Answer message to DRL 308 indicating (Hop-by-Hop=200, End-to-End=999, Result-Code=Diameter_UNABLE_TO_DELIVER).
At step 2610, DRL 308 may correlate (Appl-1, Hop=200) to (Client1, Hop=100). It may be appreciated that this mapping was done in step 2602 above.
At step 2612, DRL 308 may send an Answer message to client1 1800 indicating (Hop-by-Hop=100, End-to-End=999, Result-Code=Diameter_UNABLE_TO_DELIVER).
FIG. 27 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the DSR serves as a redirect agent for a local application according to an embodiment of the subject matter described herein. Referring to FIG. 27, at step 2700, client1 1800 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, End-to-End=999, Destination-Realm=att.com, Application ID=398).
At step 2702, DRL 308 may search its ART using Origin-Appl-ID=“Network” and find rule with Action=“Route to Local DSR” and Destination-Appl-ID=1. DRL 308 may then create a new internal transaction “200” for Appl-1 and map (Client1, Hop=100) to (Appl-1, Hop=200).
At step 2704, DRL 308 may send a Request message to FQDN1 1700 indicating (Hop-by-Hop=200, End-to-End=999, Destination-Realm=att.com, Application 10=398, “Message from Client1”).
At step 2706, local application-1 DSR Redirect Agent application 1600′ may look at information in the Request message and create a list of one or more Destinations (Redirect-Host) for routing the message.
At step 2708, local application-1 DSR Redirect Agent application 1600′ may return an Answer message to DRL 308 (Hop-by-Hop=200, End-to-End=999, Destination-Realm=att.com, Application 10=398, E-bit=1, Redirect-Host=FQDN1, Redirect-Host=FQDN2, [Redirect-Host-Usage], Result-Code=Diameter_REDIRECT_INDICATION).
At step 2710, DRL 308 may correlate (Appl-1, Hop=200) to (Client1, Hop=100). It may be appreciated that this mapping was done in step 2702 above.
At step 2712, DRL 308 may send an Answer message to client1 1800 indicating (Hop-by-Hop=100, End-to-End=999, E-bit=1, Redirect-Host=FQDN1, Redirect-Host=FQDN2, [Redirect-Host-Usage], Result-Code=Diameter_REDIRECT_INDICATION).
At step 2714, upon receipt of the Answer response with Result-Code=Diameter_REDIRECT_INDICATION, Diameter client1 1800 may attempt to route the message to the host identified in the first Redirect-Host AVP.
At step 2716, client1 1800 may send a Request message to FQDN1 1700 indicating (Hop-by-Hop=300, End-to-End=1001, Destination-Realm=att.com, Application 10=398, Dest-Host=FQDN1).
FIG. 28 is a message sequence diagram illustrating an exemplary local DSR application routing use case where the local DSR application performs decorated NAI processing according to an embodiment of the subject matter described herein. Referring to FIG. 28, at step 2800, client1 1800 may send a Request message to DRL 308 indicating (Hop-by-Hop=100, Dest-Realm=realm-Z, Appl-ID=398, User-Name=realm-X!realm-H!username@realm-Z).
At step 2802, DRL 308 may search its ART using Origin-Appl-ID=“Network” and find rule with Action=“Route to Local DSR” and Destination-Appl-ID=1. DRL 308 may then create a new internal transaction “200” for Appl-1 and map (Client1, Hop=100) to (Appl-1, Hop=200).
At step 2804, DRL 308 may send a Request message to local application-1 decorated NAI 1600″ indicating (Hop-by-Hop=200, Dest-Realm=realm-Z, Appl-ID=398, User-Name=realm-X!realm-H!username@realm-Z).
At step 2806, local DSR application-1 1600″ may perform Decorated NAI processing, return the message back to DRL for outbound routing, and drop out of the signaling path.
At step 2808, application-1 decorated NAI 1600″ may return an Answer message to DRL 308 indicating (Hop-by-Hop=200, Dest-Realm=realm-X, Appl-ID=398, User-Name=realm-Rusername@realm-X), Result-Code=Continue).
At step 2810, Answer response from Appl-1 has application-specific Result-Code=Continue (i.e., Appl-1 is requesting that Request message processing should continue). Therefore, DRL 308 may remove (Client1, Hop=100) to (Appl-1, Hop=200) mapping (performed in step 2802 above) and re-search its ART with Origin-Appl-Name=Appl-1. Finding no additional matches, DRL 308 may then search its PRT and find RRR with Route List-5 which resolves to Route-2 (Server1). DRL 308 may then create a (Client1, Hop=100) to (Server1, Hop=300) mapping.
At step 2812, DRL 308 may send a Request message to server1 1700 indicating (Hop-by-Hop=300, “Message from Appl-1”).
At step 2814, server1 1700 may return an Answer message to DRL 308 indicating (Hop-by-Hop=300, Result-Code=DIAMETER_SUCCESS).
At step 2816, DRL 308 may correlate (Server1, Hop=300) to (Client1, Hop=100). It is appreciated that this mapping was done in step 2810 above.
At step 2818, DRL 308 may send an Answer message to client1 1800 indicating (Hop-by-Hop=1000, Result-Code=DIAMETER_SUCCESS).
US8473626 * 18 Mar 2011 25 Jun 2013 Amadeus S.A.S. Method and system for providing a session in a heterogeneous environment
US20120239818 * 18 Mar 2011 20 Sep 2012 Amadeus S.A.S. Method and system for providing a session in a heterogeneous environment
EP2744172A1 * 14 Dec 2012 18 Jun 2014 Telefonica S.A. Method, system and a diameter agent node to provide communication in a diameter based protocol
WO2013188411A3 * 11 Jun 2013 24 Apr 2014 Tekelec, Inc. Methods, systems, and computer readable media for routing diameter messages at a diameter signaling router
WO2014090826A1 * 10 Dec 2013 19 Jun 2014 Telefonica, S.A. Method, system and a diameter agent node to provide communication in a diameter based protocol
European Classification H04L45/00, H04L63/08K
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CRAIG, JEFFREY ALAN;KANODE, MARK EDWARD;KARMARKAR, KEDAR KASHINATH;AND OTHERS;SIGNING DATES FROM 20110221 TO 20110415;REEL/FRAME:026189/0674
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CRAIG, JEFFREY ALAN;KANODE, MARK EDWARD;KARMARKAR, KEDAR KASHINATH;AND OTHERS;SIGNING DATES FROM 20110626 TO 20110829;REEL/FRAME:026826/0367