Abstract:
According to one aspect, the subject matter described herein includes a method of operating a Diameter signaling router (DSR) for routing Diameter messages. The method includes steps occurring at a DSR comprising a plurality of Diameter message processors, each configured to perform at least one Diameter function. The method also includes detecting, at a first of the plurality of Diameter message processors, a change in status relating to the at least one Diameter function. The method further includes communicating, by the first of the plurality of Diameter message processors and to a second of the plurality of Diameter message processors, an indication of the change in status.

Description:
PRIORITY CLAIM 
       [0001]    This application claims the benefit of U.S. Provisional Patent Application Ser. No. 61/304,310, filed Feb. 12, 2010; the disclosure of which is incorporated herein by reference in its entirety. 
     
    
     STATEMENT OF INCORPORATION BY REFERENCE 
       [0002]    The disclosures of each of the following commonly-owned, co-pending U.S. patent applications filed on Feb. 11, 2011 are hereby incorporated herein by reference in their entireties: 
         [0003]    “Methods, Systems, And Computer Readable Media For Inter-Diameter-Message Processor Routing,” Attorney Docket No. 1322/399/2 (Serial No. not yet assigned); 
         [0004]    “Methods, Systems, And Computer Readable Media For Source Peer Capacity-Based Diameter Load Sharing” Attorney Docket No. 1322/399/3 (Serial No. not yet assigned); 
         [0005]    “Methods, Systems, And Computer Readable Media For Providing Priority Routing At A Diameter Node,” Attorney Docket No. 1322/399/5 (Serial No. not yet assigned); 
         [0006]    “Methods, Systems, And Computer Readable Media For Providing Peer Routing At A Diameter Node,” Attorney Docket No. 1322/399/6/2 (Serial No. not yet assigned); 
         [0007]    “Methods, Systems, And Computer Readable Media For Providing Origin Routing At A Diameter Node,” Attorney Docket No. 1322/399/7 (Serial No. not yet assigned); 
         [0008]    “Methods, Systems, And Computer Readable Media For Providing Local Application Routing At A Diameter Node,” Attorney Docket No. 1322/399/8 (Serial No. not yet assigned); 
         [0009]    “Methods, Systems, And Computer Readable Media For Answer-Based Routing Of Diameter Request Messages,” Attorney Docket No. 1322/399/9 (Serial No. not yet assigned); 
         [0010]    “Methods, Systems, And Computer Readable Media For Performing Diameter Answer Message-Based Network Management At A Diameter Signaling Router (DSR),” Attorney Docket No. 1322/399/10 (Serial No. not yet assigned); 
         [0011]    “Methods, Systems, And Computer Readable Media For Multi-Interface Monitoring And Correlation Of Diameter Signaling Information,” Attorney Docket No. 1322/399/11 (Serial No. not yet assigned); 
         [0012]    “Methods, Systems, And Computer Readable Media For Diameter Protocol Harmonization,” Attorney Docket No. 1322/399/12 (Serial No. not yet assigned); 
         [0013]    “Methods, Systems, And Computer Readable Media For Diameter Network Management,” Attorney Docket No. 1322/399/13 (Serial No. not yet assigned); and 
         [0014]    “Methods, Systems, And Computer Readable Media For Diameter Application Loop Prevention,” Attorney Docket No. 1322/399/14 (Serial No. not yet assigned). 
       TECHNICAL FIELD 
       [0015]    The subject matter described herein relates to inter-message processor status sharing. More specifically, the subject matter relates to methods, systems, and computer readable media for inter-message processor status sharing. 
       BACKGROUND 
       [0016]    The Diameter protocol is a next generation authentication, authorization, and accounting (AAA) protocol. The Diameter base protocol is defined in IETF RFC 3588, the disclosure of which is incorporated by reference herein in its entirety. Commonly used within the Internet multimedia subsystem (IMS) architecture, the Diameter protocol was derived from the remote authentication dial-in user service (RADIUS) protocol. Historically, the RADIUS protocol was employed by Internet service providers (ISPs) to provide a secure communication channel between an ISP&#39;s access server and a secure location where user credential information was stored, e.g., a lightweight directory access protocol (LDAP) server. While the RADIUS protocol provided a standardized AAA exchange protocol, the emergence of new technologies and applications necessitated the development of a protocol capable of meeting ever-changing demands. Diameter aims to extend the standardized approach of RADIUS while providing expanded functionality and remaining open to future development. 
         [0017]    The above-referenced Diameter RFC does not specify an architecture for Diameter routing or processing nodes. Likewise, the RFC does not specify a method for inter-processor communication when a Diameter element includes a distributed architecture. Accordingly, a need exists for methods, systems, and computer readable media for inter-message processor status sharing. 
       SUMMARY 
       [0018]    According to one aspect, the subject matter described herein includes a method of operating a Diameter signaling router (DSR) for routing Diameter messages. The method includes steps occurring at a DSR comprising a plurality of Diameter message processors, each configured to perform at least one Diameter function. The method also includes detecting, at a first of the plurality of Diameter message processors, a change in status associated with the at least one Diameter function. The method further includes communicating, by the first of the plurality of Diameter message processors and to a second of the plurality of Diameter message processors, an indication of the change in status. 
         [0019]    According to another aspect, the subject matter described herein includes a system for routing Diameter messages. The system includes a Diameter signaling router including first and second Diameter message processors, each configured to implement at least one Diameter function. The first Diameter message processor is configured to detect a change in status associated with the at least one Diameter function and communicate, to the second Diameter message processor, an indication of the change in status. 
         [0020]    As used herein, the term “Diameter connection layer (DCL)” refers to a layer of the Diameter stack that implements Diameter transport connections. 
         [0021]    As used herein, the term “Diameter routing layer (DRL)” refers to a layer of the Diameter stack which implements Diameter routing. 
         [0022]    As used herein, the term “node” refers to a physical computing platform including one or more processors and memory. 
         [0023]    The subject matter described herein can be implemented in software in combination with hardware and/or firmware. For example, the subject matter described herein may be implemented in software executed by one or more processors. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer readable medium having stored thereon computer executable instructions that when executed by the processor of a computer control the computer to perform steps. Exemplary computer readable media suitable for implementing the subject matter described herein include non-transitory computer readable media, such as disk memory devices, chip memory devices, 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 device or computing platform or may be distributed across multiple devices or computing platforms. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0024]    The subject matter described herein will now be explained with reference to the accompanying drawings of which: 
           [0025]      FIG. 1  is a block diagram illustrating an exemplary DSR architecture including full stack message processors (MPs) for routing Diameter messages according to an embodiment of the subject matter described herein; 
           [0026]      FIG. 2  is a block diagram illustrating an exemplary DSR architecture including dedicated Diameter connection layer (DCL) MPs for routing Diameter messages according to an embodiment of the subject matter described herein; 
           [0027]      FIG. 3  is a block diagram illustrating an exemplary DSR architecture including dedicated DCL/DRL and application MPs for routing Diameter messages according to an embodiment of the subject matter described herein; 
           [0028]      FIG. 4  is a network diagram illustrating an exemplary Diameter networking environment which implements independent Diameter message processing nodes for routing Diameter messages between Diameter nodes and does not utilize inter-MP status sharing; 
           [0029]      FIG. 5  is a network diagram illustrating an exemplary network that includes a DSR which includes multiple MPs for routing Diameter messages utilizing inter-message processor status sharing according to an embodiment of the subject matter described herein; 
           [0030]      FIG. 6  is a message flow diagram illustrating inter-MP status sharing according to an embodiment of the subject matter described herein; and 
           [0031]      FIG. 7  is a flow chart illustrating an exemplary process for operating a DSR for routing Diameter messages according to an embodiment of the subject matter described herein. 
       
    
    
     DETAILED DESCRIPTION 
       [0032]    Methods, systems, and computer readable media for inter-MP status sharing are provided. 
         [0033]    A DSR may be any suitable entity for routing or relaying Diameter signaling messages between Diameter nodes. For example, a DSR may be a long term evolution (LTE) signaling router, an LTE Diameter signaling router, a Diameter signaling agent, a Diameter proxy agent, a Diameter relay agent, a Diameter routing agent, a Diameter translation agent, or a Diameter redirect agent. A DSR may include functionality for processing various messages. In one embodiment, a DSR may communicate with various Diameter nodes via one or more 3rd generation partnership project (3GPP) LTE communications interfaces. In another embodiment, a DSR may communicate with various Diameter nodes via one or more other (e.g., non-LTE) communications interfaces. For example, a DSR may communicate with Internet protocol (IP) multimedia subsystem (IMS) nodes, such as call session control functions (CSCFs), using IMS-related interfaces. 
         [0034]    In one embodiment, a DSR may include multiple MPs, where each MP is a distinct message processing module of a distributed computing platform, a computing blade in a blade-based distributed computing platform, a processing core element associated with a single or multi-core computing device, or a virtual node instantiated on a single physical message processing/computing device. As such, a DSR may be located in a single distinct geographic location and communicate via an internal communications network, or may include multiple MPs located in geographically diverse locations and communicating via an external communications network. 
         [0035]    As a logical entity, a DSR is extremely scalable, and may be designed according to multiple architectural options. A first architecture option may include where each MP supports a full Diameter stack that includes a DCL, a DRL, and an application layer. A second architecture option may include a DCL that runs on dedicated MPs, with routing and application layers either combined on MPs or each having dedicated MPs. A third architecture option may include a Diameter stack (DCL/DRL) that runs on dedicated MPs, with local Diameter applications running on separate dedicated MPs. Each of these exemplary architecture options will now be described in greater detail below with respect to  FIGS. 1 ,  2 , and  3 . 
         [0036]      FIG. 1  is a block diagram illustrating an exemplary DSR architecture including full stack MPs for routing Diameter messages according to an embodiment of the subject matter described herein. Referring to  FIG. 1 , DSR  100  may include ingress MP  102  for receiving Diameter messages from peers and egress MP  104  for transmitting Diameter messages to peers. Ingress MP  102  and egress MP  104  may each include a DCL, DRL, and one or more applications. For example, ingress MP  102  may include DCL  106 , DRL  108 , and application  110 . Likewise, egress MP  104  may include DCL  112 , DRL  114 , and application  116 . In order to communicate between ingress MP  102  and egress MP  104 , DRL  108  of ingress MP  102  may be operable to communicate with DRL  114  and DCL  112  of egress MP  104 . Additionally, DRLs  108  and  114  may each be operable to communicate with DCLs  106  and  112  and applications  110  and  116 , respectively. 
         [0037]    In an exemplary Diameter message routing scenario, peer N−1  118  may send a Diameter message to DSR  100 . The Diameter message may be received by DCL  106  of ingress MP  102 . Ingress messages may be processed completely on ingress MP  102  up through the selection of a next-hop peer for the Diameter message by DRL  108 . Continuing the exemplary scenario above, DCL  106  may pass the Diameter message to DRL  108 . 
         [0038]    If application processing is required, ingress DRL  108  may forward the Diameter message to a Diameter message processor hosting a local application(s). For example, DRL  108  may forward the Diameter message to an MP hosting local application  110 , which processes the message and returns the message to DRL  108 . It is appreciated that the application distribution function may not be required. 
         [0039]    Next, ingress DRL  108  may forward the Diameter message to egress DRL  114  for forwarding to the local DCL queue  112 . Egress DCL  112  may then transmit the Diameter message to peer N+1  120 . 
         [0040]    In an additional exemplary Diameter message routing scenario (not illustrated), peer N−1  118  may send a Diameter message to DSR  100 . The Diameter message may be received by DCL  106  of ingress MP  102 . DCL  106  may forward the message to DRL  108 . If application processing is required, ingress DRL  108  may forward the Diameter message to local application  110 , which processes the message and returns the message to DRL  108 . Next, ingress DRL  108  may forward the Diameter message to egress DCL  112 , which may then transmit the Diameter message to peer N+1  120 . 
         [0041]    In an additional exemplary Diameter message routing scenario (not illustrated), peer N−1  118  may send a Diameter message to DSR  100 . The Diameter message may be received by DCL  106  of ingress MP  102 . DCL  106  may pass the Diameter message to DRL  114  of egress MP  104 . If application processing is required, egress DRL  114  may forward the Diameter message to local application  116 , which processes the message and returns the message to DRL  114 . Next, egress DRL  114  may forward the Diameter message to egress DCL  112 , which may then transmit the Diameter message to peer N+1  120 . 
         [0042]      FIG. 2  is a block diagram illustrating an exemplary DSR architecture including dedicated Diameter connection layer DCL MPs for routing Diameter messages according to an embodiment of the subject matter described herein. In contrast to the full stack-per MP embodiment shown in  FIG. 1 , the embodiment shown in  FIG. 2  includes dedicated DCL MPs. Referring to  FIG. 2 , DSR  100  may include DCL-MP  200  for receiving Diameter messages from peers and DCL-MP  208  for transmitting Diameter messages to peers. Similarly, DSR  100  may include DRL-MP  202  and DRL-MP  206  for receiving Diameter messages from peers and for transmitting Diameter messages to peers. In contrast to a full stack-per MP embodiment ( FIG. 1 ), application-MP  204  may be associated with DRL-MP  202  and may not have a corollary associated with DRL-MP  206 . Nevertheless, application-MP  204  may be operable to communicate with either or both of DRL-MPs  202  and  206 . Like  FIG. 1 , DRL-MPs  202  and  206  may each be operable to communicate with one another and with DCL-MPs  200  and  208 . 
         [0043]    Therefore, in an exemplary Diameter message routing scenario analogous to the one described above with respect to  FIG. 1 , peer N−1  118  may send Diameter messages to DSR  100 . Ingress Diameter messages may be received by DCL-MP  200 , which may distribute the Diameter messages (e.g., request messages) to DRL-MP  202  based on various factors including, but not limited to, the availability, transactions per second (TPS) capacity, and congestion status of DRL-MP  202  as compared with other DRL-MPs (not shown in their entirety). 
         [0044]    DRL-MP  202  may determine whether application processing is required. If application processing is required, ingress DRL-MP  202  may distribute the request messages to Appl-MP  204  (also based on its availability, TPS capacity, and congestion status). 
         [0045]    Ingress DRL-MP  202  may then select a next-hop peer for the messages and ingress DRL-MP  202  may forward the messages to egress DRL-MP  206 . Egress DRL-MP  206  may then forward the messages to egress DCL-MP  208  (highest degree on inter-MP communication) for delivery to peer N+1  120  selected by DRL-MP  202 . 
         [0046]    In an additional exemplary Diameter message routing scenario (not illustrated), peer N−1  118  may send Diameter messages to DSR  100 . Ingress Diameter messages may be received by DCL-MP  200 , which may distribute the Diameter messages (e.g., request messages) to DRL-MP  202  based on various factors including, but not limited to, the availability, TPS capacity, and congestion status of DRL-MP  202  as compared with other DRL-MPs (not shown in their entirety). DRL-MP  202  may determine whether application processing is required. If application processing is required, ingress DRL-MP  202  may distribute the request messages to Appl-MP  204  (also based on its availability, TPS capacity, and congestion status). Ingress DRL-MP  202  may then select a next-hop peer for the messages and ingress DRL-MP  202  may forward the messages to egress DCL-MP  208  for delivery to peer N+1  120  selected by DRL-MP  202 . 
         [0047]    In an additional exemplary Diameter message routing scenario (not illustrated), peer N−1  118  may send Diameter messages to DSR  100 . Ingress Diameter messages may be received by DCL MP  200 , which may distribute the Diameter messages (e.g., request messages) to DRL-MP  206  based on various factors including, but not limited to, the availability, TPS capacity, and congestion status of DRL-MP  206  as compared with other DRL-MPs (not shown in their entirety). DRL-MP  206  may determine whether application processing is required. If application processing is required, DRL-MP  206  may distribute the request messages to Appl-MP  204  (also based on its availability, TPS capacity, and congestion status). DRL-MP  206  may then select a next-hop peer for the messages and DRL-MP  206  may forward the messages to egress DCL-MP  208  for delivery to peer N+1  120  selected by DRL-MP  206 . 
         [0048]      FIG. 3  is a block diagram illustrating an exemplary DSR architecture including dedicated DCL/DRL and application MPs for routing Diameter messages according to an embodiment of the subject matter described herein. It may be appreciated that  FIG. 3  represents a hybrid approach between the full stack per MP of  FIG. 1  and the dedicated DCL/DRL/application-MPs of  FIG. 2 . Referring to  FIG. 3 , in an exemplary Diameter message routing scenario, peer N−1  118  may send a Diameter message to DSR  100 . The Diameter message may be received by DCL  106  of ingress MP  102 . The Diameter message may be processed completely on ingress MP  102  up through the selection of a destination peer for the Diameter message by DRL  108 . DCL  106  may then pass the Diameter message to DRL  108 . 
         [0049]    If application processing is required, ingress DRL  108  may forward the Diameter message to local application(s). For example, DRL  108  may forward the Diameter message to local application  204 , which may process the message and return the message to DRL  108 . 
         [0050]    Next, ingress DRL  108  may forward the Diameter message to egress DRL  114  for forwarding to the local DCL queue  112 . Egress DCL  112  may then transmit the Diameter message to peer N+1  120 . 
         [0051]    In an additional exemplary Diameter message routing scenario (not illustrated), peer N−1  118  may send a Diameter message to DSR  100 . The Diameter message may be received by DCL  106  of ingress MP  102 . The Diameter message may be processed completely on ingress MP  102  up through the selection of a destination peer for the Diameter message by DRL  108 . DCL  106  may then pass the Diameter message to DRL  108 . If application processing is required, ingress DRL  108  may forward the Diameter message to local application(s). For example, DRL  108  may forward the Diameter message to local application  204 , which may process the message and return the message to DRL  108 . Next, ingress DRL  108  may forward the Diameter message to DCL  112  which may then transmit the Diameter message to peer N+1  120 . 
         [0052]    In an additional exemplary Diameter message routing scenario (not illustrated), peer N−1  118  may send a Diameter message to DSR  100 . The Diameter message may be received by DCL  106  of ingress MP  102 . DCL  106  may then pass the Diameter message to DRL  114 . If application processing is required, DRL  114  may forward the Diameter message to local application(s). For example, DRL  114  may forward the Diameter message to local application  204 , which may process the message and return the message to DRL  114 . Next, DRL  114  may forward the Diameter message to DCL  112  which may then transmit the Diameter message to peer N+1  120 . 
         [0053]    Irrespective of the architectural option implemented, utilization of a DSR may benefit from the ability of the individual MPs to share change in their respective statuses. Exemplary MP status information may include, but is not limited to, status information associated with one or more Diameter connections hosted/serviced by the MP, status information associated with one or more Diameter signaling routes serviced by the MP, status information associated with one or more SCTP associations hosted/serviced by the MP, status information associated with one or more Diameter peer nodes serviced by/accessed via the MP, status information associated with one or more TCP sockets hosted/serviced by the MP, status information associated with one or more Internet protocol addresses hosted/serviced by the MP, status information associated with one or more database resources hosted/serviced by the MP, and status information associated with one or more Diameter applications hosted by/serviced by/accessed via the MP. Exemplary types of status information may include, but are not limited to, availability status information, congestion status information, active/standby status information, in-service/out-of-service status information, failure state status information, software version status information, hardware version status information, firmware version status information, upgrade status information, message processing/transaction rate status information. The sharing of such “peer status” may, for example, be utilized by the ingress MP to determine the status of route lists, route groups, and routes which are prerequisite to route selection. In other embodiments a local MP may share its congestion status in order to aide its peers in routing. For example, if an egress MP is experiencing critical congestion, inter-MP status sharing may allow ingress MP to take this into consideration during route selection.  FIGS. 4 and 5  illustrate an exemplary benefit of utilizing inter-MP status sharing in such a scenario. 
         [0054]      FIG. 4  is a network diagram illustrating an exemplary Diameter networking environment which implements independent Diameter message processing nodes for routing Diameter messages between Diameter nodes and does not utilize inter-MP status sharing. Referring to  FIG. 4 , network  400  includes Diameter peer nodes  402 ,  404 , and  406 . Diameter peer nodes  404  and  406  are in a common Diameter realm  408 . Network  400 , further includes independent Diameter message processing nodes  410 ,  412 , and  414 . A Diameter connection  416  exists between Diameter peer node  402  and Diameter message processing node  410 . Similarly, Diameter connection  418  exists between Diameter peer node  404  and Diameter message processing node  412 ; Diameter connection  420  exists between Diameter peer node  406  and Diameter message processing node  414 ; and Diameter connection  422  exists between Diameter peer node  404  and Diameter message processing node  414 . 
         [0055]    As  FIG. 4  illustrates, Diameter messaging processing node  410  is load sharing messages coming from Diameter peer node  402  and destined for Diameter realm  408  between Diameter message processing nodes  412  and  414  at a 50/50 ratio. A route failure exists along Diameter connection  418 . While Diameter message processing node  412  may be aware of the route failure along Diameter connection  418 , Diameter message processing node  410  remains unaware. Without knowledge of the route failure along Diameter connection  418 , Diameter message processing node  410  continues to load share half of the messages from Diameter peer node  402  and destined for Diameter realm  408  to Diameter message processing node  412 . Operating network  400  in such a manner results in half of the routing attempts performed by Diameter message processing node  410  failing and having to be rerouted. 
         [0056]      FIG. 5  is a network diagram illustrating an exemplary network that includes a DSR which includes multiple MPs for routing Diameter messages utilizing inter-MP status sharing according to an embodiment of the subject matter described herein. Referring to  FIG. 5 , network  500  includes Diameter peer nodes  502 ,  504 , and  506 . Diameter peer nodes  504  and  506  are in a common Diameter realm  508 . Network  500 , further includes DSR  510 . DSR  510  may include multiple Diameter message processors. For example, DSR  510  includes Diameter message processors  512 ,  514 , and  516 . A Diameter connection  518  exists between Diameter peer node  502  and DSR  510 &#39;s Diameter MP  512 . Similarly, Diameter connection  520  exists between Diameter peer node  504  and DSR  510 &#39;s Diameter MP  514 ; Diameter connection  522  exists between Diameter peer node  506  and DSR  510 &#39;s Diameter MP  516 ; and Diameter connection  524  exists between Diameter peer node  504  and DSR  510 &#39;s Diameter MP  516 . 
         [0057]    As  FIG. 5  illustrates, DSR  510 &#39;s Diameter MP  512 W may load share messages coming from Diameter peer node  502  and destined for Diameter realm  508  between DSR  510 &#39;s Diameter MPs  514  and  516 . Prior to a route failure along Diameter connection  520 , this load sharing may be at a 50/50 ratio (not illustrated). A route failure may arise along Diameter connection  520 . In accordance with an embodiment of the subject matter described herein, DSR  510 &#39;s Diameter MP  514  may share information pertaining to its status (e.g., route failure exists along Diameter connection  520 ) with its peer, DSR  510 &#39;s Diameter MP  512 . In response, DSR  510 &#39;s Diameter MP  512  may alter the load sharing ratio to 0/100 so that all Diameter messages from Diameter peer node  502  and destined for Diameter realm  508  are routed through DSR  510 &#39;s MP  516 . Similarly, if and when the route failure along Diameter connection  520  is resolved, DSR  510 &#39;s MP  514  may share information pertaining to its status (e.g., Diameter connection  520  “up”) with its peer, DSR  510 &#39;s Diameter MP  512 , which may then resume load sharing messages coming from Diameter peer node  502  and destined for Diameter realm  508  between DSR  510 &#39;s Diameter MPs  514  and  516  at a 50/50 ratio (not illustrated). In an alternate example, when Diameter connection  520  fails, DSR  510 &#39;s MP  512  may, upon learning of the change in status, redirect messages destined for Diameter peer node  504  to DSR  510 &#39;s MP  516 . 
         [0058]    In one embodiment, DSR  510  may include MP status database (DB)  526 . MP status DB  526  may be accessible to DSR  510 &#39;s Diameter MPs  512 ,  514 , and  516 . In accordance with an embodiment of the subject matter described herein, MP status DB  526  may be utilized for inter-MP status sharing. For example, in the above scenario, DSR  510 &#39;s Diameter MP  514  may update MP status DB  526  to reflect the route failure along Diameter connection  520 . DSR  510 &#39;s Diameter MP  512  may be configured to query MP status DB  526  and/or MP status DP  526  may be configured to broadcast/multicast status information to any or all of DSR  510 &#39;s Diameter MPs. 
         [0059]      FIG. 6  is a message flow diagram illustrating inter-MP status sharing according to an embodiment of the subject matter described herein. Referring to the route failure scenario described above with respect to  FIG. 5 , DSR  510 &#39;s Diameter MP  512  is load sharing messages coming from Diameter peer node  502  and destined for Diameter realm  508  between DSR  510 &#39;s Diameter MPs  514  and  516  at a 50/50 ratio. Referring to  FIG. 6 , just prior to step  1 , the route failure occurs along Diameter connection  520 . DSR  510 &#39;s Diameter MP  514  detects the route failure along Diameter connection  520 . At step  1 , DSR  510 &#39;s Diameter MP  514  sends an inter-MP status message to its peer, DSR  510 &#39;s Diameter MP  512 , communicating the change in its status as a result of the failure along Diameter connection  520 . 
         [0060]      FIG. 7  is a flow chart illustrating an exemplary process for operating a DSR for routing Diameter messages according to an embodiment of the subject matter described herein. Referring to  FIG. 7 , in step  700 , a first Diameter message processor detects a change in status relating to a Diameter function performed by the Diameter message processor. For example, as set forth above, the first Diameter message processor may perform Diameter routing and may detect a change in status of a peer Diameter node or a connection that affects a Diameter route. In step  702 , the first Diameter message processor communicates an indication of the change in status to a second Diameter message processor. For example, the first Diameter message processor may send a message to the second Diameter message processor communicating the identity of the affected route and the route status to the second Diameter message processor. In an alternate implementation, the first Diameter message processor may update a central routing table or other data structure indicating the change in status. 
         [0061]    It will be understood that various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation, as the subject matter described herein is defined by the claims as set forth hereinafter.