Patent Publication Number: US-11388082-B2

Title: Methods, systems, and computer readable media for diameter routing using software defined network (SDN) functionality

Description:
TECHNICAL FIELD 
     The subject matter described herein relates to determining policy information. More specifically, the subject matter relates to methods, systems, and computer readable media for Diameter routing using software defined network (SDN) functionality. 
     BACKGROUND 
     In telecommunications networks, global Internet protocol traffic is increasing at a rate of forty to fifty percent per year. In order to retain subscribers, it is desirable for service providers to keep monthly charges to subscribers relatively unchanged. Keeping charges constant with increasing traffic requires a reduction in expenses. For example, with a forty percent increase in traffic, service providers must reduce capital expenses and operational expenses by forty to fifty percent per gigabyte per second per year to achieve relatively constant pricing. 
     One possible method for reducing capital and operational expenses is to use software defined networks (SDNs). SDNs can be used to manage flows, control switches, control network access, and track user location and motion. SDNs can also be used to efficiently utilize network components. For example, SDNs may be used to power off unused equipment during non-peak periods to conserve energy. 
     Some SDN models may centralize the control of network elements, such as routers and switches, by removing intelligence from the routers and switches and placing that intelligence in a centralized location. One such effort to provide centralized control of routers and switches is the OpenFlow architecture described in the OpenFlow Switch Specification, Version 1.1.0, Feb. 28, 2011, the disclosure of which is incorporated herein by reference in its entirety. Conventionally, SDN architecture has not been used to control telecommunications network elements. 
     Accordingly, a need exists for methods, systems, and computer readable media for Diameter routing using SDN functionality. 
     SUMMARY 
     Methods, systems, and computer readable media for routing a Diameter message are disclosed. According to one method, the method occurs at a Diameter routing node. The method includes receiving, from a Diameter routing controller (DRC) via an SDN related interface, Diameter routing information, wherein the Diameter routing information is determined using application layer information. The method also includes routing a Diameter message using the Diameter routing information. 
     According to one system, the system includes a Diameter routing node. The Diameter routing node comprises an SDN related interface configured to receive, from a DRC, Diameter routing information, wherein the Diameter routing information is determined using application layer information. The Diameter routing node also includes a routing module configured to route a Diameter message using the Diameter routing information. 
     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 in software executed by a processor. In one exemplary implementation, the subject matter described herein may be implemented using a 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 devices, 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. 
     As used herein, the term “node” refers to a physical computing platform including one or more processors and memory. 
     As used herein, the terms “function” or “module” refer to hardware, firmware, or software in combination with hardware and/or firmware for implementing features described herein. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The subject matter described herein will now be explained with reference to the accompanying drawings of which: 
         FIG. 1  is a diagram illustrating exemplary SDN components according to an embodiment of the subject matter described herein; 
         FIG. 2  is a diagram illustrating an exemplary DRC and an exemplary Diameter routing node (DRN) according to an embodiment of the subject matter described herein; 
         FIGS. 3A and 3B  are diagrams illustrating exemplary Diameter routing information according to an embodiment of the subject matter described herein; 
         FIG. 4  is a diagram illustrating exemplary messages associated with routing a Diameter message according to an embodiment of the subject matter described herein; 
         FIG. 5  is a diagram illustrating exemplary messages associated with providing Diameter information about one or more newly available Diameter resources according to an embodiment of the subject matter described herein; and 
         FIG. 6  is a diagram illustrating an exemplary process for routing a Diameter message according to an embodiment of the subject matter described herein. 
     
    
    
     DETAILED DESCRIPTION 
     The subject matter described herein discloses methods, systems, and computer readable media for Diameter routing using SDN functionality. Diameter is an authentication, authorization, and accounting (AAA) application layer protocol for computer networks, and is a successor to RADIUS. The Diameter base protocol is defined in IETF RFC 6733, the disclosure of which is incorporated by reference herein in its entirety. Diameter communications may use a request-answer message exchange. Diameter routing involves routing of request messages in one direction and answer messages in the reverse direction. 
     In accordance with some aspects of the subject matter described herein, a Diameter routing node may use SDN functionality and/or SDN components. For example, a Diameter router node (e.g., a Diameter routing agent (DRA) or Diameter signaling router (DSR)) may communicate with a Diameter routing controller (DRC). In this example, the Diameter routing node may receive routing decisions and/or Diameter routing information from the DRC. In some embodiments, the DRC and the Diameter routing node may communicate using an SDN related interface, such as an OpenFlow protocol interface or a Diameter protocol interface. 
     In accordance with some aspects of the subject matter described herein, a Diameter routing node may route Diameter messages without performing application layer (e.g., open systems interconnection (OSI) model layer 7) analysis. For example, an initial Diameter request message may be received by a Diameter routing node. The Diameter routing node may query a DRC (e.g., via an SDN related interface) for Diameter routing information associated with the Diameter request message. In this example, the Diameter routing information may include an Internet protocol (IP) address and/or port information associated with a destination node. The Diameter routing node may associate Diameter routing information received from the DRC (e.g., via an SDN related interface) and non-application layer information associated with the Diameter message (e.g., an IP data tuple associated with an IP packet containing the Diameter message). For example, an IP data tuple may include a source IP address, a destination IP address, a source port number, a destination port number, and/or a transport protocol. In this example, the IP data tuple may be usable to identify related Diameter session or flows and may be referred to as a session data flow (SDF) filters. Using an IP data tuple or other information, the Diameter routing node may identify and route related Diameter messages to the same destination node indicated by the previously received Diameter routing information, e.g., without querying the DRC or performing application layer analysis on the related Diameter messages. 
     Advantageously, by using SDN functionality and/or SDN components, a Diameter routing node may route Diameter messages while conserving resources, e.g., resources typically used when performing application layer processing. By querying and receiving routing decisions and/or Diameter routing information via an SDN related interface, a Diameter routing node in accordance with aspects of the subject matter described herein may conserve more resources than a conventional Diameter routing node. 
     Additionally, by using SDN functionality and/or SDN components, information about newly (e.g., recently) available Diameter resources may be provided to a Diameter routing node. For example, Diameter routing information about a newly available Diameter network node (e.g., a Diameter application server) may be provided to a Diameter routing node, thereby allowing the Diameter routing node to dynamically route Diameter messages to the newly available Diameter resource. 
     Reference will now be made in detail to exemplary embodiments of the subject matter described herein, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. 
       FIG. 1  is a diagram illustrating exemplary SDN components according to an embodiment of the subject matter described herein. In some embodiments, various nodes may be associated with or controlled by SDN functionality. Referring to  FIG. 1 , exemplary SDN components may include a network orchestrator  100 , a DRC  102 , Diameter routing node (DRN)  104 - 108 , and/or nodes  110 - 116 . Network orchestrator  100  may represent any suitable entity (e.g., software executing on a processor) for monitoring network events and/or hardware events. For example, network orchestrator  100  may communicate with various entities (e.g., (e.g., various nodes, network operators, or other sources) and may determine whether a node, a resource, or a network segment is overloaded, experiencing problems, or operating normally. Network orchestrator  100  may use received or derived information to predict future conditions (e.g., network congestion or node failures). Network orchestrator  100  may include functionality for allocating or reallocating various network resources, such as Diameter resources (e.g., Diameter network functions, Diameter nodes, or resources at Diameter functions or nodes), based on monitored or predicted conditions. For example, network orchestrator  100  may include virtualization functionality for dynamically allocating or reallocate hardware resources associated with a physical device and for instantiating needed resource instances using hardware associated with the physical device. 
     DRC  102  may represent any suitable entity (e.g., software executing on a processor) for performing Diameter routing decisions and/or providing Diameter routing information. For example, DRC  102  may communicate with one or more of DRNs  104 - 108  via an SDN related interface. Exemplary SDN related interfaces may include an OpenFlow protocol interface or a Diameter protocol interface. DRC  102  may receive Diameter messages or related information from one or more of DRNs  104 - 108 . DRC  102  may determine an appropriate destination for received Diameter messages, e.g., by analyzing or inspecting application layer information (e.g., a Diameter realm identifier (ID), a Diameter command code, a Diameter node name, etc.) associated with the Diameter messages. DRC  102  may provide Diameter routing information to one or more of DRNs  104 - 108 , e.g., via an SDN related interface. Exemplary Diameter routing information may include address information and/or other identifying information associated with a destination, such as an IP address and/or port information, a uniform resource identifier (URI), a fully qualified domain name (FQDN), or other information. 
     Each of DRNs  104 - 108  may represent any suitable entity (e.g., software executing on a processor) for routing Diameter signaling messages. For example, each of DRNs  104 - 108  may be an LTE signaling router, an LTE Diameter signaling router, a Diameter proxy, a Diameter agent, a Diameter routing agent, a Diameter relay agent, Diameter translation agent, or a Diameter redirect agent. Each of DRNs  104 - 108  may include functionality for processing various messages. In some embodiments, such functionality may be included in one or more modules (e.g., a firewall module, a network address translation (NAT) module, a subscriber location module, and/or a routing module). It will be appreciated that functionality and modules as used herein refers to hardware, software, firmware, or any combination of hardware, software, and firmware for implementing the features described herein. 
     Each of DRNs  104 - 108  may include functionality for receiving, processing, and/or switching or routing various messages and may include various communications interfaces for communicating with Diameter nodes, e.g., 3rd Generation Partnership Project (3GPP) LTE communications interfaces and other (e.g., non-LTE) communications interfaces. Exemplary communications interfaces for communicating with Diameter nodes may include an LTE interface, an IMS interface, an IETF specification interface, a 3GPP specification interface, a Third Generation Partnership Project 2 (3GPP2) specification interface, a European Telecommunications Standards Institute (ETSI) specification interface, an International Telecommunications Union (ITU) specification interface, a PacketCable specification interface, a MultiService Forum (MSF) specification interface, an Sh interface, a Dx interface, a Ro interface, a Rf interface, an Sp interface, a Gx interface, a Rx interface, a Gz interface, a Gy interface, a Gq interface, a Zh interface, a Dz interface, a Zn interface, a Ty interface, a Tx interface, a Dw interface, a Wa interface, a Wd interface, a Wx interface, a Wm interface, a Wg interface, a Pr interface, a Gr interface, a Gr+ interface, a Gi interface, a Wo interface, a Wf interface, a Re interface, an S6 interface, an S2 interface, an SW interface, an Sta interface, an S7 interface, an H2 interface, an E2 interface, an E4 interface, an E5 interface, a A3 interface, a A4 interface, a Rr interface, a Gq′ interface, a TC-6 interface, a TC-7 interface, a TC-8 interface, a TC-9 interface, a TC-10 interface, a TC-11 interface, a DB-0 interface, a DB-2 interface, a BI-1 interface, a LOC-1 interface, an Rw interface, a Pkt-mm-2 interface, a P-CSCF-PAM interface, a Pkt-laes-2 interface, an MM10 interface, an MZ interface, a Gmb interface, or a Zn′ interface. 
     Each of DRNs  104 - 108  may include functionality for receiving, processing, and/or switching or routing SDN related messages and may include various communications interfaces for communicating with SDN related nodes or components, e.g., a Diameter protocol interface or an OpenFlow protocol interface. 
     In some embodiments, each of DRNs  104 - 108  may be configurable for communicating with DRC  102  and/or network orchestrator  100 , e.g., via an SDN related interface. For example, DRN  104  may request or query DRC  102  for Diameter routing information. DRC  102  may determine appropriate Diameter routing information and provide the Diameter routing information to DRN  104 . In response to receiving the Diameter routing information, DRN  104  may store the Diameter routing information in a local or otherwise accessible routing table and may use the Diameter routing information for routing Diameter messages. In another example, DRN  104  may provide statistics or other status information to network orchestrator  100 . Network orchestrator  100  may use the information to direct, provision, or control DRN  104 , DRC  102 , and/or other nodes, e.g., by triggering DRC  102  to provide Diameter routing information to DRN  104  or by sending SDN related commands directly to DRN  104 . 
     In some embodiments, SDN related messages (e.g., from DRC  102  or network orchestrator  100 ) may be solicited (e.g., by DRN  104  sending a request message) or may be unsolicited (e.g., an SDN related message may be sent to DRN  104  for provisioning a Diameter routing table without a corresponding request message from DRN  104 ). 
     Each of DRNs  104 - 108  may facilitate communication between Diameter clients and Diameter servers. For example, a Diameter client may send a Diameter request message (e.g., a Diameter session establishment request message) to DRN  108 . The Diameter request message may require one or more services from a Diameter server. DRN  108  may route, relay, and/or translate requests or responses between the Diameter client and the Diameter server. After receiving and processing the Diameter request message, the Diameter server may send a Diameter response message (e.g., a Diameter session establishment response message) to DRN  108 . The Diameter response message may be sent in response to the Diameter request message originated by the Diameter client. DRN  108  may provide the Diameter response message to the Diameter client, e.g., using Diameter routing information. 
     Each of nodes  110 - 116  may represent any suitable entity (e.g., software executing on a processor) capable of communicating using a Diameter-based protocol. For example, each of nodes  110 - 116  may be a Diameter client, a Diameter server, a mobility management entity (MME), a home subscriber server (HSS), an authentication, authorization, and/or accounting (AAA) server, a Diameter application server, a subscriber profile repository (SPR), or other Diameter node. Each of nodes  110 - 116  may include functionality for processing various messages. For example, nodes  110 - 116  may represent a plurality of HSSs, where each HSS contains subscriber-related information, such as user identification, control information for user authentication and authorization, location information, and user profile data. 
     In some embodiments, DRNs  104 - 108  and nodes  110 - 116  may be associated with SDNs  118  and  120 . Each of SDN  118  and  120  may represent a network containing one or more nodes (or virtual nodes). For example, network orchestrator  100  may allocate or trigger allocation of resources (e.g., using DRC  102 ) and configure resources such that DRN  104  is associated with SDN  118  and DRNs  106  and  108  are associated with SDN  120 . In this example, DRC  102  may provide Diameter routing information or configure routing table data such that DRN  104  routes Diameter messages to nodes  110  and  112 , while DRC  102  may provide Diameter routing information or configure routing table data such that DRNs  106  and  108  route Diameter messages to nodes  112 ,  114 , and  116 . 
     It will be appreciated that  FIG. 1  is for illustrative purposes and that various nodes, their locations, and/or their functions described above in relation to  FIG. 1  may be changed, altered, added, or removed. For example, some nodes and/or functions may be combined into a single entity, e.g., network orchestrator  100  and DRC  102  may be included in a single policy and charging rules function (PCRF) node or a single Diameter Routing Agent (DRA) node. In a second example, a node and/or function may be located at or implemented by two or more nodes, e.g., DRC  102  may be distributed across multiple nodes for handling multiple SDNs  118  and  120 . 
       FIG. 2  is a diagram illustrating exemplary DRC  102  and exemplary DRN  104  according to an embodiment of the subject matter described herein. In some embodiments, DRC  102  and DRC  104  may be configurable to include multiple logical nodes, modules, or functions. 
     Referring to  FIG. 2 , DRC  102  may include a policy-based Diameter routing agent (PDRA) controller  200  and an offline charging system (OFCS) controller  202 . PDRA controller  200  may represent any suitable entity for determining and/or providing Diameter routing information. PDRA controller  200  may include or access a PCRF. For example, PDRA controller  200  may use policy information provided by a PCRF in determining policy decisions. In this example, policy information may include policy and charging control (PCC) rules and may indicate that certain subscribers receive enhanced services or features. Using policy information, PDRA controller  200  may route Diameter messages associated with a particular subscriber or session to an appropriate destination. 
     OFCS controller  202  may represent any suitable entity for determining and/or providing charging related information. OFCS controller  202  may include or access a charging trigger function (CTF), a charging data function (CDF), and/or a charging gateway function (CGF). For example, OFCS controller  202  may determine how a subscriber, session, or service should be charged or billed. In this example, charging information may be provided to DRN  104  or logical Diameter router  206  such that a particular session can be billed appropriately, e.g., without requiring DRN  104  to perform its own OFCS related analysis. 
     DRN  104  may include logical Diameter routers  204  and  206 . For example, each of logical Diameter routers  204  and  206  may use physical resources associated with DRN  104 . Each of logical Diameter routers  204  and  206  may include modules, memory, and/or other components associated with routing Diameter messages. For example, logical Diameter router  204  may include a routing module  208 , an SDN interface  210 , and a Diameter routing table  212  and logical Diameter router  206  may include a routing module  214 , an SDN interface  216 , and a Diameter routing table  218 . 
     Each of routing modules  208  and  214  may represent any suitable entity for routing Diameter messages. For example, routing module  208  or routing module  214  may use one or more physical interfaces for receiving and/or sending Diameter messages and may include functionality for routing a Diameter message to a destination using Diameter routing information, e.g., received via SDN interface  210  and/or stored in Diameter routing table  212 . 
     Each of SDN interfaces  210  and  216  may represent any suitable entity for receiving and/or sending SDN related messages. For example, SDN interface  210  or SDN interface  216  may include one or more physical interfaces for communicating with DRC  102 , PDRA controller  200 , OFCS controller  202 , or network orchestrator  100 . 
     Each of Diameter routing tables  212  and  218  may represent any suitable entity (e.g., a non-transitory computer readable medium) for storing or maintaining Diameter routing information. For example, Diameter routing tables  212  and  218  may include associations between Diameter sessions, Diameter services or applications, or subscriber IDs and network node address information. 
       FIG. 3A  is a diagram illustrating exemplary Diameter routing information  300  according to an embodiment of the subject matter described herein. In some embodiments, exemplary routing data  300  may be accessed and/or stored by DRNs  104 ,  106 , and/or  108  using various data structures. 
     Referring to  FIG. 3A , Diameter routing information  300  may include associations between subscriber IDs and network node address information and may be depicted using a table. The routing table of  FIG. 3A  may include a subscriber ID field, a network node URI field, a network node FQDN field, and a network node IP address field. Subscriber ID field may include subscriber or device identifiers (or portions thereof), such as an international mobile subscriber identity (IMSI), a mobile subscriber integrated services digital network (MSISDN) number, a short code, a URI, IMEI, and a mobile identification number (MIN). Network node URI, FQDN, and IP address fields represents fields for storing address information or routing information for nodes. 
     As depicted in  FIG. 3A , Diameter routing information  300  may indicate an association between an IMSI (e.g., IMSI value: “310012353464342”) and a network node associated with a URI (e.g., URI value: “aaa://host.example.com:1813;transport=udp;protocol=radius”). Diameter routing information  300  may also indicate a second association between a portion of an IMSI (e.g., IMSI portion value: “314024*”) and a network node associated with a URI (e.g., URI value: “hss://hss1.vzw.net:1815;transport=udp; protocol=radius;protocol=radius”), an FQDN (e.g., FQDN value: “HSS1@VZW.NET”), and an IP address (e.g., IP address value: “192.53.34.11 port number: 1815”). By using a portion of an IMSI followed by a wildcard ‘*’ character, the second association may indicate a group of subscribers (e.g., subscribers having the same initial 6 digits for their IMSI values) that are associated with a particular node. Diameter routing information  300  may also indicate a third association between a portion of an IMSI (e.g., IMSI portion value: “220412353464342”) and a network node associated with an IP address (e.g., IP address value: “192.23.43.12 port number: 64”). Diameter routing information  300  may also indicate other associations between IMSIs or portions thereof and one or more network node identifiers for identifying associated nodes. 
     In some embodiments, Diameter routing information  300  may indicate associations between Diameter sessions and network nodes. For example, a first Diameter session may be associated with first node, while a second session may be associated with a second node. In some embodiments, Diameter routing information  300  may indicate associations between Diameter services or applications and network nodes. For example, a registration service may be associated with a first node, while a credit control service may be associated with a second node. 
     In some embodiments, DRC  102  and/or network orchestrator  100  may provide Diameter routing information  300  to DRNs  104 ,  106 , and/or  108 . For example, using SDN related interfaces and/or related messages, DRC  102  may configure or provision Diameter routing table  212  using various factors, e.g., current load of a resource or network segment, predicted load of a resource or network segment, resource problems, a new resource becoming available, a resource becoming unavailable, a time of day, subscriber or device issues, or other factors. By providing Diameter routing information  300  and/or provisioning Diameter routing tables, DRC  102  and/or network orchestrator  100  may dynamically adjust current or predicted network conditions and/or may modify SDN boundaries (e.g., by including additional nodes as possible destinations for Diameter messages or by removing nodes as possible destinations for Diameter messages). 
     Referring to  FIG. 3B , Diameter routing information  302  may represent Diameter routing information  300  that is modified after one or more SDN related messages from DRC  102  and/or network orchestrator  100 . The routing table of  FIG. 3B  may include similar or identical fields as the routing table of  FIG. 3A . As depicted in  FIG. 3B , Diameter routing information  302  may be modified to route Diameter messages to different network nodes than indicated by Diameter routing information  300 . For example, Diameter routing information  302  may include an association between a portion of an IMSI (e.g., IMSI portion value: “314024*”) and a network node associated with a URI (e.g., URI value: “hss://hss3.vzw.net:1815;transport=udp; protocol=radius”), an FQDN (e.g., FQDN value: “HSS3@VZW.NET”), and an IP address (e.g., IP address value: “192.53.34.41 port number: 1815”). Diameter routing information  302  may also include an association between a portion of an IMSI (e.g., IMSI portion value: “458712353468745”) and a network node associated with a URI (e.g., URI value: “hss://hss4.vzw.net:1815;transport=udp;protocol=radius”), an FQDN (e.g., FQDN value: “HSS4@VZW.NET”), and an IP address (e.g., IP address value: “192.53.34.42 port number: 1815”). 
     It will be appreciated that Diameter routing information  300  and  302  may vary depending on the communications network, configuration, messages, and network nodes involved. For example, types of addressing or routing information may vary for network nodes. In another example, Diameter routing information  300  and  302  may include network layer address information for identifying a network node in lieu of a FQDN or URI. 
     In some embodiments, each association may be between a subscriber ID or a Diameter session or service and address information associated with a particular network node. In such embodiments, multiple entries may be used to identify additional nodes. 
     In some embodiments, each association may be between a subscriber ID or a Diameter session or service and one or more associated nodes (e.g., backup or secondary node addresses). In such embodiments, additional fields (e.g., backup node fields) may be used to identify additional nodes. 
     In some embodiments, Diameter routing information  300  or Diameter routing information  302  may include one or more status fields for identifying whether an associated node is currently available, experiencing problems, or inactive. 
       FIG. 4  is a diagram illustrating exemplary messages associated with routing a Diameter message according to an embodiment of the subject matter described herein. In some embodiments, node  110  may be an HSS for maintaining subscriber location information pertaining to a subset of network subscribers. In some embodiments, MME  300  may be an MME for managing mobility events associated with one or more subscribers. 
     Referring to  FIG. 4 , at step  1 , a mobility management message may be received at a MME  300 . In some embodiments, the received mobility management message may be a registration message referred to as a tracking area update (TAU) message. The TAU message or registration message may be initiated by a user device when the user device detects entering a tracking area that is not previously registered in MME  300  for use by the user device. The TAU message may include UE-related information, such as an IMSI or other device identifier. 
     At step  2 , in response to receiving the mobility management message, a Diameter message may be generated and sent from MME  300  to DRN  104 . For example, MME  300  may generate and send an Update-Location-Request (ULR) message in response to receiving the TAU message. The ULR message may include various parameters, such as the IMSI value associated with the TAU message. 
     In some embodiments, MME  300  may not determine or may be unable to provide address information or routing information for sending the Diameter message to an appropriate destination. DRN  104  may be configured to receive and route such messages to appropriate destinations. 
     In some embodiments, DRN  104  may receive a ULR message sent by MME  300 . DRN  104  may examine the received Diameter message and may determine whether and/or how to route the message. For example, network orchestrator  100  may allocate or otherwise nodes  110 - 116  in a communications network to distribute or reduce processing load on any particular one of nodes  110 - 116 . In this example, if nodes  110 - 116  do not include identical data, it may be necessary to identify the node that contains a particular subscriber&#39;s data when attempting to route messages. 
     In some embodiments where subscribers or sessions are handled by a plurality of nodes  110 - 116 , DRN  104  may query accessible Diameter routing information (e.g., stored in a local Diameter routing table) for determining an appropriate destination. In some embodiments, querying accessible Diameter routing information may involve using non-application layer information (e.g., an IP data tuple) associated with a Diameter message that is to be routed. 
     In some embodiments, DRN  104  may be unable to determine addressing or routing information. For example, if an appropriate destination is not found in accessible Diameter routing information, DRN  104  may be capable of requesting Diameter routing information from other nodes, such as DRC  102  or network orchestrator  100  via an SDN related interface. 
     At step  3 , an SDN related message for requesting Diameter routing information may be sent from DRN  104  to DRC  102 . For example, DRN  104  may request Diameter routing information from DRC  102  by sending a route information request message via an SDN related interface. The route information request message may include various information associated with the corresponding Diameter message, such as a subscriber identifier and/or session related information. 
     In some embodiments, DRC  102  may receive a route information request message and may use information stored in the route information request message for determining an appropriate destination. For example, DRC  102  may analyze application layer information, such as Diameter identifiers, stored in the route information request message to determine an appropriate destination. 
     At step  4 , an SDN related message for providing Diameter routing information may be sent from DRC  102  to DRN  104 . For example, DRC  102  may provide Diameter routing information to DRN  104  by sending a route information answer message via an SDN related interface. After receiving Diameter routing information from DRC  102 , DRN  104  may store the Diameter routing information and may use this information for routing Diameter messages. 
     In some embodiments, using Diameter routing information provided by DRC  102 , DRN  104  may determine an appropriate destination, e.g., node  110 , for a Diameter message. After determining an appropriate destination for a received Diameter message, DRN  104  may modify the Diameter message, e.g., to include the destination information, prior to routing the Diameter message. 
     At step  5 , the Diameter message may be sent from DRN  104  to node  110 . For example, DRN  104  may send a modified ULR message to node  110 . 
     In some embodiments, node  110  may receive a Diameter message and respond. For example, in response to receiving an ULR message, node  110  may send an Update-Location-Answer (ULA) message indicating that location information was received and stored. 
     At step  6 , a Diameter answer message may be sent from node  110  to MME  300 . For example, DRN  104  may send a ULA message to node  110 . 
     At step  7 , a second mobility management message may be received at a MME  300 . In some embodiments, the second mobility management message may be a TAU message indicating that a user device is entering a tracking area that is not previously registered in the MME  300  for use by the user device. The TAU message may include UE-related information, such as an IMSI or other device identifier. 
     At step  8 , in response to receiving the mobility management message, a Diameter message may be generated and sent from MME  300  to DRN  104 . For example, MME  300  may generate and send an Update-Location-Request (ULR) message in response to receiving the TAU message. The ULR message may include various parameters, such as the IMSI value associated with the TAU message. 
     DRN  104  may examine the received Diameter message and may determine whether and/or how to route the message. For example, DRN  104  may query accessible Diameter routing information (e.g., stored in a local Diameter routing table) for determining an appropriate destination. In some embodiments, querying accessible Diameter routing information may involve using non-application layer information associated with the Diameter message. 
     Using accessible Diameter routing information (e.g., previously provided by DRC  102 ), DRN  104  may determine an appropriate destination, e.g., node  110 , for a Diameter message. After determining an appropriate destination for a received Diameter message, DRN  104  may modify the Diameter message, e.g., to include the destination information, prior to routing the Diameter message. 
     At step  9 , the Diameter message may be sent from DRN  104  to node  110 . For example, DRN  104  may send a modified ULR message to node  110 . 
     In some embodiments, node  110  may receive a Diameter message and respond. For example, in response to receiving an ULR message, node  110  may send an Update-Location-Answer (ULA) message indicating that location information was received and stored. 
     It will also be appreciated that the above described messages are for illustrative purposes and that different and/or additional messages may be used. 
       FIG. 5  is a diagram illustrating exemplary messages associated with providing Diameter information about one or more newly available Diameter resources according to an embodiment of the subject matter described herein. In some embodiments, network orchestrator  100  may be configured to instantiate, allocate, or make available one or more Diameter resources (e.g., a Diameter network function or node or additional resources for an existing function or node). For example, network orchestrator  100  may instantiate Diameter resources dynamically (e.g., in response to monitored information, network conditions, or a request from a network node) or statically (e.g., based on preconfigured instructions or directives). In such embodiments, network orchestrator  100  may provide relevant information, such as Diameter routing information, about newly available Diameter resources to DRC  102  or DRN  104  and/or other nodes. By providing the relevant information to DRC  102 , Diameter destinations associated with the newly available Diameter resources may be added to a Diameter routing table at DRC  102 . DRC  102  may then communicate the Diameter destinations to DRN  104 , whereby DRN  104  may use this information to route Diameter messages, readjust load balancing algorithm(s), or readjust failure handling algorithm(s) to the newly available Diameter resources. 
     Referring to  FIG. 5 , at step  500 , network orchestrator  100  may allocate or instantiate one or more Diameter resources, e.g., for use in a Diameter-based network. For example, network orchestrator  100  may determine that one or more additional Diameter resources (e.g., HSS5@VZW.NET) may be useful for handling an increase in Diameter traffic associated with a particular SDN or portion therein. In this example, network orchestrator  100  may use received information, from other external system, such as another orchestrator or monitoring system, about components in the SDN and/or other relevant information in determining to make available additional Diameter resources. 
     At step  501 , an SDN related message for providing Diameter routing information, or information appropriate for that diameter function, may be sent from network orchestrator  100  to DRC  102 . For example, a Diameter routing table (DRT) provisioning message may be sent from network orchestrator  100  to DRC  102 . The DRT provisioning message may include Diameter routing information about a newly available Diameter resource, e.g., the Diameter routing information may include a network node FQDN and/or an IP address and port information. In this example, DRC  102  may use the included Diameter routing information to update a Diameter routing table. 
     At step  502 , an SDN related message for acknowledging reception of Diameter routing information may be sent from DRC  102  to network orchestrator  100 . For example DRC  102  may send a DRT provisioning answer message indicating that Diameter routing information was successfully received. 
     At step  503 , a Diameter ULR message may be generated and sent to DRN  104 . For example, MME  300  may generate and send a ULR message in response to receiving a TAU message. The ULR message may include various parameters, such as the IMSI value associated with the TAU message. 
     In some embodiments, DRN  104  may be unable to determine addressing or routing information. For example, if an appropriate destination is not found in accessible Diameter routing information, DRN  104  may be capable of requesting Diameter routing information from other nodes, such as DRC  102  or network orchestrator  100  via an SDN related interface. 
     At step  504 , an SDN related message for requesting Diameter routing information may be sent from DRN  104  to DRC  102 . For example, DRN  104  may request Diameter routing information from DRC  102  by sending a route information request message via an SDN related interface. The route information request message may include various information associated with the corresponding Diameter message, such as a subscriber identifier and/or session related information. 
     In some embodiments, DRC  102  may receive a route information request message and may use information stored in the route information request message for determining an appropriate destination. For example, DRC  102  may analyze application layer information, such as Diameter identifiers, stored in the route information request message and may determine that a newly available Diameter resource is an appropriate destination. 
     At step  505 , an SDN related message for providing Diameter routing information may be sent from DRC  102  to DRN  104 . For example, DRC  102  may provide Diameter routing information to DRN  104  by sending a route information answer message via an SDN related interface. The route information answer message may include Diameter routing information about a newly available Diameter resource (e.g., HSS5@VZW.NET). After receiving Diameter routing information from DRC  102 , DRN  104  may store the Diameter routing information and/or may use this information for routing Diameter messages to the newly available Diameter resource. 
     In some embodiments, DRN  104  may modify the Diameter message, e.g., to include the Diameter routing information received from DRC  102 , prior to routing the Diameter message to the newly available Diameter resource. 
     It will also be appreciated that the above described messages are for illustrative purposes and that different and/or additional messages may be used. For example, network orchestrator  100  may communicate Diameter routing information to DRN  102  directly (e.g., without using DRC  102 ). In this example, network orchestrator  100  may send a DRT provisioning message to DRN  104  and DRN  104  may respond with a DRT provisioning answer message to network orchestrator. In another example, DRC  102  may provide Diameter routing information about a newly available Diameter resource to a DRN  102  unilaterally (e.g., automatically or without DRN  104  requesting routing information). 
       FIG. 6  is a diagram illustrating an exemplary process  600  for routing a Diameter message according to an embodiment of the subject matter described herein. In some embodiments, exemplary process  600 , or portions thereof, may be performed by or at DRN  104 , DRN  106 , DRN  108 , DRC  102 , network orchestrator  100 , routing module  208 , routing module  214 , logical Diameter router  204 , logical Diameter router  206 , PDRA controller  200 , OFCS controller  202 , and/or another node or module. In some embodiments, exemplary process  600  may include steps  602  and/or  604 . 
     At step  602 , Diameter routing information may be received from DRC  102  via an SDN related interface (e.g., SDN interface  210 ). In some embodiments, the Diameter routing information may be determined using application layer information, e.g., a Diameter realm identifier, a Diameter control code, a Diameter service or application identifier, and/or a Diameter node URI or FQDN. 
     In some embodiments, Diameter routing information may include switching information (e.g., layer 2 and/or layer 3 information). In such embodiments, routing a Diameter message using Diameter routing information may include switching the Diameter message using the switching information 
     In some embodiments, Diameter routing information may be received in response to the DRN  104  querying DRC  102  for the Diameter routing information after receiving a Diameter request message for initiating a Diameter session or an initial Diameter message. 
     In some embodiments, DRN  104  may use previously obtained Diameter routing information for routing Diameter message. For example, after receiving Diameter routing information for a particular session from DRC  102 , DRN  104  may receive a second Diameter message associated with the Diameter session and may route the second Diameter message using the Diameter routing information associated with that particular session. 
     In some embodiments, Diameter router information may be received in response to network orchestrator  100  or DRC  102  determining that DRN  104  should receive the Diameter routing information based on a current condition or a predicted future condition. 
     In some embodiments, an SDN related interface may include an OpenFlow protocol interface, a network virtualization using generic routing encapsulation (NVGRE) protocol interface, a virtual extensible LAN (VXLAN) protocol interface, a forwarding and control element separation (ForCES) protocol interface, a locator/ID separation protocol (LISP) interface, an open vSwitch database management (OVSDB) protocol interface, a border gateway protocol (BGP) interface, a BGP link-state (BGP-LS) protocol interface, a path computation element protocol (PCEP) interface, a network configuration (NETCONF) protocol interface, a simple network management protocol (SNMP) interface, or a Diameter protocol interface. For example, SDN related interface may be used for communicating between DRC  102  and DRN  104 . 
     In some embodiments, DRC  102  may include a PCRF, an OFCS, and/or network orchestrator  100 . For example, DRC  102  may be capable of determining routing decisions based on policy information, subscriber credit information, and/or various network conditions. 
     In some embodiments, DRC  102  may be configured to communicate with network orchestrator  100 . In such embodiments, network orchestrator  100  may be configured to monitor or predict network conditions and may allocate or reallocate various network resources based on the monitored or the predicted network conditions. 
     In some embodiments, Diameter routing information may include address information associated with a destination node or a second Diameter routing node, layer 2 information, layer 3 information, layer 4 information, layer 5 information, layer 6 information, layer 7 information, switching information, an IP address, port information, Diameter application layer information, a Diameter realm ID, a Diameter command code, a Diameter node name, a URI, and/or an FQDN. 
     At step  602 , a Diameter message may be routed using the Diameter routing information. For example, DRN  104  may route a Diameter message to node  110  using address information determined and provided by DRC  102 . 
     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.