Controlling distribution and routing from messaging protocol

TECHNICAL FIELD

This disclosure relates generally to controlling distribution and routing from a messaging protocol.

BACKGROUND

In various types of network infrastructures, different types of routing schemes (e.g., unicasting, multicasting, broadcasting) can be utilized for delivery of messages and may be useful in different circumstances. However, some communications protocols may be unable to efficiently utilize certain types of routing schemes. The use of different types of communications casting can become further complicated when a message is communicated across systems using multiple communication protocols, such as may be required for new devices and existing (e.g., legacy) devices that may be incapable of leveraging certain newer messaging protocols.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> depicts an example of a mapping system.

<figref idref="DRAWINGS">FIG. 2</figref> depicts an example of a communication system communicating messages in a messaging protocol.

<figref idref="DRAWINGS">FIG. 3</figref> depicts an example of a cable system that can implement a mapping system in a messaging protocol.

<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram depicting an example of a method for mapping messages.

<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram depicting another example of a method for mapping messages.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

This disclosure relates generally to controlling distribution and routing from a messaging protocol, such as an Internet Protocol (IP) based messaging and presence protocol.

In some examples a mapping system can be configured with logic that processes messages provided to one or more services according to a messaging protocol. The message can include a service address that identifies one of the services in the messaging protocol. The service address can also include a mask that is utilized by the mapping system to control how the message will be distributed to one or more recipient nodes. For example, the mask can be applied to control provisioning of a message to multiple recipient nodes (e.g., corresponding to masking cast). The mask can also be applied to control provisioning of a message to one or more endpoint devices via respective control nodes (e.g., corresponding to host casting).

As an example, the mapping system can provide a proxy interface to address routing of messages to and/or from traditional controllers using the existing interfaces on such traditional controllers. As a further example, the message can be delivered to one or more recipient nodes, as determined by the mapping system, using a service interface that is selected according to a service identifier in the service address of the message. The recipient node (e.g., a controller of a hybrid fiber coaxial (HFC) cable access network) can further control distribution of the message. For example, each recipient node can include distribution mapping data that specifies a type of distribution (e.g., unicast, multicast or broadcast) based on the mask that is provided in the message. In other examples, the recipient can be a final endpoint of the message, which can also be determined based on the mask and the mapping data.

Example Embodiments

<figref idref="DRAWINGS">FIG. 1</figref> depicts an example of a mapping system <b>10</b>. The mapping system <b>10</b> provides a mechanism to enable an internet protocol (IP)-based messaging protocol to be utilized for routing and delivery of various messages efficiently through existing service interfaces utilized by nodes coupled to the mapping system. Such existing service interfaces can employ non-IP based protocols, IP-based protocols or a combination of non-IP and IP-based protocols, including proprietary and/or standards based communication protocols. The mapping system <b>10</b> can be implemented in a computer system and may implement instructions stored in a non-transitory computer readable medium that are executable by a processor (e.g., including one or more processor cores). For example, the mapping system <b>10</b> can be implemented in a router or other device that is configured to implement the functions disclosed herein.

The mapping system can reside in a service domain that is addressable according to a messaging and presence protocol. As used herein, the messaging and presence protocol provides a technology infrastructure that provides for the asynchronous, end-to-end exchange of structured data by means of direct, persistent information (e.g., XML) streams among a distributed network of globally addressable, presence-aware clients (e.g., endpoints) and services. IP messaging and presence protocols operate in the application layer of the OSI model. The application layer provides for communications protocols, including the IP messaging and presence protocols, for process-to-process communications across an IP computer network. As such, the messaging and presence protocols employ underlying transport layer protocols to enable various connections.

Examples of messaging and presence protocols that can be utilized by the mapping system <b>10</b> include the extensible messaging and presence protocol (XMPP), such as defined by the internet engineer task force under Worker's Specifications RFC 6120 RFC 6121, RFC 6122, and RFC 3923. Other IP-based message-oriented application level middleware and protocols can be utilized by the mapping system <b>10</b> (e.g., the advanced message queuing protocol (AMQP)).

The mapping system <b>10</b> thus can operate as a proxy in a messaging and presence protocol and provide service translation, routing and distribution of messages based on a service address of a given message. As an example, in addition to the service address (e.g., a well formed Jabber construct) operating to deliver a message to a service domain that is supported by the mapping system <b>10</b> according to a corresponding messaging protocol, the same service address can also include data that provides for translation, routing and delivery of the message by the mapping system to one or more recipient nodes. Each recipient node can be a device, a service or application, which is capable of receiving and/or sending messages. In some examples, the recipient node can be a control system or a service associated with operation of a control system for a hybrid fiber coaxial (HFC) cable access network, such as can reside at a headend or other location.

In the example of <figref idref="DRAWINGS">FIG. 1</figref>, a messaging interface <b>12</b> can receive a given message that is addressed to a service in a respective service domain of the messaging and presence protocol. In some examples, the messaging interface <b>12</b> can be capable of receiving messages for any number of one or more services in a given domain supported by the mapping system <b>10</b>. Presence information for each service thus can be advertised (e.g., by the messaging interface) as respective services via a service directory implemented in the messaging and presence protocol through which the messages can be sent. The mapping system thus operates as the proxy for receiving messages addressed to each respective service in the domain. The messaging interface <b>12</b> can also be configured to communicate messages from the mapping system <b>10</b> to the messaging protocol such as to one or more end points in the same or different domains. As an example, a given domain can be associated with a router or other topological components that may exist in the application layer (e.g., layer <b>7</b>) where the messaging protocol operates. As mentioned above, the application layer protocol thus can be implemented as a messaging and presence protocol, such as XMPP or the like.

The mapping system <b>10</b> can include logic <b>14</b> that is configured to process a message that is received by the message interface <b>12</b> (e.g., for a supported service address) and distribute the message to one or more recipient nodes based on the service address in the message and mapping data <b>16</b>. The service address in a given message can include a service identifier and a mask. The service identifier, for example, can identify both a unique service that includes a respective service interface <b>18</b> that is configured to communicate over an existing protocol with one or more endpoint nodes. For example, a service address may be implemented as a well formed construct in the messaging and presence protocol, such as follows: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0017">SERVICE_ID@domain/mask <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0018">where the SERVICE_ID is a unique identifier, such as an address or the like, for a service that can operate as an endpoint in the messaging and presence protocol;</li><li id="ul0003-0002" num="0019">“domain” is a prescribed domain in the messaging and presence protocol in which one or more endpoints reside; and</li><li id="ul0003-0003" num="0020">“mask” is a value that is used to control routing and distribution of the message to one or more recipients and the mode of delivery to such recipients.</li></ul></li></ul></li></ul>

In some examples, the service interface can provide for communication of command, control and/or provisioning messages to one or more control systems in a HFC cable access network (also referred to as a cable television system). One or more such control systems can be legacy systems that are incapable of communicating command, control and/or provisioning instructions via the messaging and presence protocol; and the mapping system <b>10</b> thus can operate as a proxy for distributing and routing service messages selectively to the control systems. The services messages can be provided by control plane services for the CATV system, which may or may not be configured to communicate via the messaging and presence protocol. The control system can consume the message internally, such as for configuring the control system based on the command, control and/or provisioning instructions in the message. Alternatively, the control system can control distribution of the message to one or more endpoint devices (e.g., customer premises equipment) for configuring the endpoint device(s) based on the command, control and/or provisioning instructions in the message.

In the example of <figref idref="DRAWINGS">FIG. 1</figref>, the logic <b>14</b> includes a mapping agent <b>20</b> and a distribution control <b>22</b>. The mapping agent <b>20</b> is configured to determine at least one recipient node (e.g., a downstream control system) for the given message based on applying the mask to predetermined mapping data <b>16</b>. The mapping data <b>16</b> can include a data structure representing a list of recipient nodes for each service that is supported by the mapping system <b>10</b>. For example, the mapping data <b>16</b> can specify recipient metadata for a set of recipient nodes and their respective identifiers (e.g., controller IDs) for each of the nodes supported. The mapping agent <b>20</b> thus can utilize a respective service identifier in the service address of a given message to select which set of recipient nodes are potential recipients, and the mask can be applied to the corresponding metadata to determine destination nodes for the given message.

As a further example, the mapping agent <b>20</b> can include an address calculator <b>24</b> that is configured to compute an address (e.g., a network address) for each recipient based on applying the mask to each respective address of recipient nodes in the corresponding list that has been selected from the mapping data (e.g., by the mapping agent) based on the service identifier. For example, where a message includes a service identifier for a given service, the address calculator <b>24</b> can apply the mask to each recipient node that is associated with such given service to compute a corresponding network address for the node (e.g., a predefined node ID).

As a further example, the mapping agent <b>20</b> can convert the mask to a binary representation that includes a predetermined number of bits that is commensurate with a binary representation of the node address. In some examples, the mask and node addresses can each be four bites long such that they can be easily mapped to the notion of IP addresses and subnet masking to facilitate assignment of the systems with ID's based on routing and distribution needs of the system. It is to be understood, however, that other forms of masking and identifiers can be utilized in other operations than bitwise operations may be utilized to perform the respective functions associated with routing and delivery of the messages.

The address calculator <b>24</b> can perform a bitwise operation between the bits corresponding to the mask relative to a corresponding binary representation of the addresses for each of the recipient nodes associated with the respective service. For example, the bitwise operation can correspond to a bitwise ANDing between the mask and the node address stored in the mapping data <b>16</b> for each of the recipient nodes for the identified service. The address calculator <b>24</b> thus can provide a computed address that can correspond to one or more recipient nodes to which the message can be distributed via the corresponding service interface <b>18</b>. There can be any number of service interfaces <b>18</b> to support communication with each respective service that is supported by the mapping system.

In addition to the application of the mask specifying which one or more recipient nodes the message is to be distributed, the mask can also control subsequent distribution of the message by the recipient node. For example, the mapping agent <b>20</b> can include a matching function <b>26</b> that is configured to determine a mode of delivery for the message to each identified recipient node. The matching function <b>26</b> can determine the mode of delivery based on the mask and the computed address for the recipient. For example, the matching function <b>26</b> can implement logic to determine whether a match exists based upon applying the mask to the address computed by the address calculator, such as in a bitwise operation.

As an example, the matching function <b>26</b> can determine, based upon the bitwise operation, whether the message is to be delivered to a single recipient node, multicast to a proper subset of two or more recipient nodes or if the message is to be broadcast to each of the recipient nodes via the service interface <b>18</b>. As a further example, the matching function <b>26</b> can determine that the mode of delivery for the message is unicast delivery to a single node in response to determining an exact match based on the mask and the address that is computed by the address calculator <b>24</b>. As another example, the matching function can be configured to provide the message via the service interface <b>18</b> for delivery to a group of nodes in response to computing a match based on applying the mask to the computed address for each of the nodes in the respective group. In some examples, the group of nodes can correspond to a service delivery region (e.g., one or more hubs or other downstream plant region). In other examples, the group can correspond to a proper subset of nodes (e.g., control systems). Thus, the mask can be configured by the sender of the message (e.g., a control plane service) to control routing and delivery of the message to recipient nodes for each corresponding service that is supported by the service interface <b>18</b>.

The distribution control <b>22</b> is configured to process the message and provide the process message to a respective service interface <b>18</b> based on the service identifier in the service address of the incoming message. The distribution control <b>22</b> can include message translation function <b>28</b>, a service agent <b>30</b>, and a protocol adapter <b>32</b>. The service agent <b>30</b> is configured to select a given service interface that is utilized for delivering the message to each recipient based on the service identifier in the message's service address. As mentioned above, there can be one or more recipient nodes to which the message is to be routed, and thus the service agent <b>30</b> can select appropriate service interfaces to enable communication of the message from the mapping system <b>10</b> to each recipient node. For example, in certain systems (e.g., CATV distribution plants), different control systems may implement different communication protocols for a given service. Thus the service agent <b>30</b> can select the appropriate service interface to enable communication of the service message to each respective recipient node.

The translation function <b>28</b> of the distribution control <b>22</b> can be implemented as machine executable instructions stored in memory in such a manner as can be executed by a processor. The translation function <b>28</b> can be configured to process a message received via a messaging and presence protocol and prepare the relevant content in the message for delivery to a given endpoint based on the service identifier in the service address. The translation can be from an IP-based protocol to a non-IP communications protocol that is utilized by the recipient node, for example. Since the message includes the service identifier, as part of the service address construct, in some examples, the translation function <b>28</b> can control routing of the message directly from the service identifier in the message without explicit look up in memory. The translation function <b>28</b> can re-format the message for delivery to one or more recipient nodes determined by the mapping agent <b>20</b>. The translation function <b>28</b> can perform the conversion of messages based on the mapping data <b>16</b> that is stored in memory. Alternatively, the translation function <b>28</b> can generate instructions identifying communication parameters to implement the delivery to the endpoint node(s) based on the service identifier and mapping data <b>16</b>. The translation function <b>28</b> can also embed the initial SERVICE_ID/mask in the communication parameter.

The distribution control <b>22</b> can also include a protocol adapter <b>32</b> configured to convert the message to given protocol for communication to the recipient node(s) based on the converted message and instructions from the translation function <b>28</b>. For instance, the translation function <b>28</b> can provide a converted message (e.g., according to an XML schema) that specifies each recipient node (e.g., a network address), other instructions (e.g., command) and protocol requirements. The protocol adapter <b>32</b> can thus be programmed to repackage the message from the IP messaging and presence protocol for transmission to a given non-IP endpoint according to protocol requirements of each recipient node (e.g., an application layer protocol that is implemented by a control system).

As an example, the protocol adapter function <b>32</b> can be configured to repackage the message according to the business and operations support system (BOSS) interface, which was developed by Scientific-Atlanta, Inc. Other protocols can be used, which will vary according to application requirements and capabilities of the resource nodes to which the message is sent. Examples of some other protocols in the context of a HFC cable access network can include a broadcast file system (BFS) API, a pass through API (PTAPI), loadPIMS or the like. The protocol adapter <b>32</b> can adapt the message for communication according to other application layer interfaces. The protocol adaption function <b>32</b> can also be utilized for adapting communication transaction requests and responses between the mapping system <b>10</b> and the IP messaging and presence layer. Additionally, the protocol adaption function <b>32</b> can be configured to implement multiple protocols such as to support communication with a plurality of different devices that might employ different protocols. For example, a given mapping system <b>10</b> can be configured to support a digital access controller, a digital network control system (e.g., from Cisco Systems, Inc.) as well as control systems from other manufacturers.

In view of the foregoing, it is to be understood and appreciated that the mapping agent, including the address calculator <b>24</b> and matching function <b>26</b>, can effectively operate as a filter, which employs the service address for controlling delivery of the message to a selected recipient node or multiple recipient nodes based on applying the mask to node information (e.g., node addresses) stored in the mapping data <b>16</b>. The mapping system can thus operate as a proxy for any number of services to enable the translation, routing and distribution of messages from services via a newer protocol that is not supported by all recipient nodes. In this way, a provider can continue to utilize legacy distribution and endpoint devices while certain communication protocols are upgraded in other parts of the system. Moreover, the upgrades can be modular since the mapping system <b>10</b> is scalable to support such changes in a distributed manner. Efficiencies in communications can also be achieved since, for example, the mapping system enables a single message to be translated into multiple messages for multiple client endpoints, rather than sending individual messages to the client endpoints.

<figref idref="DRAWINGS">FIG. 2</figref> depicts an example of a system <b>100</b> that can be utilized for sending messages for distribution delivery by a mapping system (e.g., a mapping system <b>10</b> of <figref idref="DRAWINGS">FIG. 1</figref>). In the example of <figref idref="DRAWINGS">FIG. 2</figref>, the system <b>10</b> includes a service <b>102</b> that is configured for providing a message via an IP-based messaging and presence protocol and which can be processed by a mapping system for delivery to one or more recipient nodes. The mode of delivery (e.g., message casting) will be specified and assigned by the service <b>102</b>, and it can vary according to the type of service or content of the message.

In some examples, the service <b>102</b> can correspond to a control plane or a management service that is implemented in or controlled by a provider of a CATV distribution system and the recipient node(s) can be one or more control systems in a head end, one or more hubs and/or one or more customer premises equipment (CPE). Examples of the service <b>102</b> can include a billing system, firmware management services, channel map management services or the like. Thus, in some examples, the service <b>102</b> can be programmed to send a message; to a given control system downstream in a cable distribution plant, to one or more control systems or broadcast to all control systems. The service <b>102</b> can be activated to provide the command or control instructions in the message in response to a user input or in response to a call to an application that is associated with the service <b>102</b>.

In other examples, the service <b>102</b> can send a given message to a given control system for distribution to one or more further downstream devices, such as CPE or to a designated group of CPEs (e.g., a hub). As an example, a billing system can be programmed to send billing information to a given CPE in response to a user ordering a pay per view (PPV) program. In other examples, a group of CPEs, corresponding to different customers within a hub of a cable distribution plant, may be sent updates or status information associated with a channel map unique to the area in which the CPEs reside. In other examples, the service <b>102</b> can provide an upgrade message (e.g., containing firmware updates) to CPE equipment, which can be all CPEs in the cable system or a selected subset of CPEs. Thus, the identification of CPEs and control systems of the cable distribution plant can be specified by the service <b>102</b> for constructing the service address of the message which includes a service identifier and a mask that are utilized for controlling delivery and routing of the message by a corresponding mapping system. However, the service and/or the recipient node(s) may not be configured to send or receive the message via a messaging and presence protocol. If the service <b>102</b> cannot directly employ the messaging and presence protocol, the service <b>102</b> can utilize a protocol adapter <b>104</b> that is configured to enable the service <b>102</b> to access a service translation function <b>106</b>. In other examples, the service translation function <b>106</b> can be implemented as part of the service or the service can access the service translation function directly without the protocol adapter.

In the example of <figref idref="DRAWINGS">FIG. 2</figref>, the service translation function <b>106</b> is configured to construct a message in response to the request from the service <b>102</b>. The message can include a message body, which can include command and control instructions, as well as a service address. The service address can include a service identifier, which uniquely identifies a service in a given service domain, and a corresponding mask, such as disclosed herein (e.g., SERVICE_ID@domain/mask).

The service translation function <b>106</b> thus can be configured for communication over a messaging protocol fabric, such as may implement an IP-based presence and messaging protocol (e.g., XMPP). Thus the service translation function <b>106</b> can include a messaging interface <b>108</b> that is configured to provide for a transmission and receipt of messages via the messaging fabric. The service translation function <b>106</b> can also include a service mapping function <b>110</b> that is configured to map the request to a corresponding service of an associated service domain based upon mapping data that may be contained in a mapping database <b>112</b>. The mapping database <b>112</b> can be implemented as a computer readable medium that may be local relative to the service translation function <b>106</b> or may be distributed across a network in one or more memory structures. The service mapping function <b>110</b> employs the associated data in the mapping database to determine a mode of delivery and service to which the corresponding message is to be sent.

As a further example, the service translation function <b>106</b> can include a mask generator <b>114</b> configured to determine a mask for the message. The mask has a value designed to enable delivery of the message to one or more intended recipient nodes. The mask can further be utilized to determine a mode of delivery (e.g., unicast, multicast or broadcast) to communicate the message to one or more intended recipient nodes. For example, the mask can include a mask value (e.g., in a hexadecimal) that can be converted to a binary representation of an address that can be applied to node addresses associated with a given service and service domain to compute an identity of each recipient node and specify a predetermined mode of delivery for the message. In some examples, the mask can also include an identification that maps to further downstream delivery from the recipient node to one or more devices (e.g., CPEs). The one or more devices can include a specific device downstream from the control system, a group of devices (e.g., a logical service region that includes multiple devices), such as a hub of a cable distribution plant or specify a broadcast to all devices downstream from a recipient node. Thus each recipient node can be programmed with a data structure (e.g., look-up table) that specifies delivery mode for different mask values. The mask generator <b>114</b> thus constructs the mask according to the requirements in the instructions from the service <b>102</b> based on the mapping data in the mapping database <b>112</b>. The mapping database <b>112</b> contains information, such as in the form of a look-up table, to enable the mask generator to construct the appropriate mask for delivery of the message to each of the intended recipients.

The service mapping function <b>110</b> combines the service identifier and domain information with the mask to provide a corresponding service address for the message that is to be sent. In some cases, the service translation function <b>106</b> may generate multiple messages in the event that a single message is incapable of reaching each of the intended recipient nodes. A protocol translation function <b>116</b> can translate the message, including the service address, to the appropriate protocol for distribution and delivery via the messaging fabric. For example, the protocol translation function <b>116</b> can encapsulate command and control data into message payload with the service address provided as a header for delivery by the messaging interface <b>108</b> to a router <b>120</b> via the messaging and presence protocol. In some examples, the service <b>102</b> can be configured for native operation in the messaging and presence protocol and communicate directly with the domain <b>122</b>. For instance, when the service is in the same domain as the router <b>120</b>, the service <b>102</b> can connect to messaging and presence protocol fabric using a service connection manager (SCM) <b>128</b>, which is configured to adapt service communications (e.g., service requests and response) to the messaging and presence protocol and vice versa. As another example, the SCM <b>128</b> may reside external to the domain <b>122</b>, and it could communicate with the router <b>120</b> via a router-to-router protocol that encapsulates the application level messaging and presence protocol. For example, the service translation <b>106</b> may employ the messaging interface <b>108</b> to construct or deconstruct messages communicated with a specified service (e.g., in the S1.DOMAIN.COM).

The router <b>120</b> forms part of a domain <b>122</b> demonstrated in the example of <figref idref="DRAWINGS">FIG. 2</figref> as R1.domain.com. The domain <b>122</b> can provide a hierarchical distributed naming system for devices, services or other resources to communicate via a transport layer. A system <b>100</b> can include any number of domains and services. Thus, each IP resource operating in the domain <b>122</b> can be provided a unique identity for communications within the domain according to the messaging and presence protocol. The router <b>120</b> can also employ a router-to-router (R2R) protocol for connecting to other routers in a network, such as an intranet, a wide area network (WAN) or a cloud-based infrastructure. The router-to-router (R2R) protocol thus encapsulates messages being communicated in the application level messaging and presence protocol.

The domain <b>122</b> can include one or more services (e.g., service <b>2</b>) <b>124</b>, which may be internal services of the domain or external services that connect via a connection manager, such as disclosed herein. The service <b>124</b>, further, can connect to an external system (e.g., via an API) to access information and methods to provide service-related functions. The domain <b>122</b> can also include and one or more connection managers (CM) <b>126</b> configured to provide IP connectivity (e.g., using TCPI/IP) to one or more IP-based endpoints <b>130</b>. Each connection manager <b>126</b>, <b>128</b> may reside on the same virtual machine or on a separate machine from where the router <b>54</b> resides. For example, each of the IP-based endpoints <b>130</b> can be configured to operate in the IP messaging and presence protocol (e.g., XMPP) environment. The IP endpoint <b>130</b>, for example, may connect to the connection manager <b>126</b> through an IP connection (e.g., TCP/IP) such as may be made via a modem or other type of network interface that provides a means for communicating via the IP messaging and presence protocol that is managed by the connection manager. For instance, each endpoint <b>130</b> can be configured to advertise its own presence via the IP messaging and presence protocol. Additionally, in the example system <b>100</b>, the messaging and presence command and control layer of domain <b>122</b> can control each IP-based endpoint <b>130</b>.

As mentioned above, the message provided by the service <b>102</b> can be sent to an identified service, which resides in a service domain device <b>134</b>. The service domain device <b>134</b> includes a service mapping system <b>136</b> that is configured to support any number of one or more services for translation, routing and distribution of a given message to one or more recipient nodes based on a service address in the message and service mapping data <b>138</b>, as disclosed herein. In some examples, the service domain of device <b>134</b> can be a separate domain from the R.DOMAIN.COM domain <b>122</b>, and can communicate with the domain <b>122</b> via router-to-router protocol or a server-to-server-protocol. In other examples, the service domain of device <b>134</b> can reside within the R1.DOMAIN.COM domain <b>122</b>, and connect to a service connection manager (e.g., SCM <b>128</b>) operating in the messaging protocol. The service mapping system <b>136</b> can thus provide a service domain proxy for each such service in a given service domain, which in this example is demonstrated as S2.DOMAIN.COM. The service mapping system <b>136</b> can be configured according to the example of system <b>10</b> disclosed with respect to <figref idref="DRAWINGS">FIG. 1</figref>.

As mentioned, the device <b>134</b> can itself include a router (not shown) and communicate with the messaging and protocol fabric to another domain <b>122</b> such as using a router-to-router protocol. In other examples, the device <b>134</b> can operate as a connection manager and communicate directly with the messaging protocol fabric. For instance, the service domain device <b>134</b> can include a presence manager <b>142</b> that is configured to perform an advertisement function to register and advertise each of the services in the domain via corresponding service directory that is implemented in the messaging protocol fabric. Each service or device implemented in the domain can communicate with other endpoints registered in the messaging and presence protocol. As disclosed with respect to <figref idref="DRAWINGS">FIG. 2</figref>, the unique identifiers for each of the services supported in the domain can include a corresponding service ID and mask, which can be set in response to a service request by the service <b>102</b> (e.g., a control plane service) to provide for translation, routing and distribution to one or more recipient nodes by the device <b>134</b>.

The service mapping system <b>136</b> can employ a service identifier to uniquely identify one or more control system interfaces <b>144</b>. The interfaces <b>144</b>, for example, can support functionalities that can vary according to the services <b>102</b> or <b>124</b> that are communicating the messages and the appropriate functionalities of the respective recipient nodes. Examples of some control system interfaces <b>144</b> in the context of a CATV system can include BOSS, PTAPI, BFS API, LOAD PIMS, SFTP or the like. The service mapping system <b>136</b> further can perform translation and distribution of the message to the appropriate interface <b>144</b> for communication of the message downstream. As mentioned above, the service mapping data <b>138</b> can include metadata that identifies each of the control systems or other types of recipient nodes to which the message can be communicated. The device <b>134</b> can also include a network interface <b>140</b> to provide for communication with a network via which the messaging protocol fabric can be communicated. The network interface, for example can implement a lower level protocol, such as TCP/IP or the like, on which the application level messaging and presence protocol fabric may be implemented. The use of a service mapping system thus enables each of the services <b>102</b> or <b>124</b> to ubiquitously use the same messaging mechanism via the IP messaging and presence protocol (e.g., XMPP) to implement command and control for both IP-based endpoints <b>130</b> and non-IP based endpoints (not shown). Hence, translation from the IP messaging presence and protocol to the protocol-adapted message for delivery to the non-IP endpoints can be facilitated.

<figref idref="DRAWINGS">FIG. 3</figref> depicts an example of part of a cable television system <b>200</b> that can implement message routing and delivery using a service mapping system <b>202</b> to provide for translation, routing and distribution of messages. The system <b>200</b> employs a messaging and presence protocol (e.g., XMPP) to communicate messages in an application layer of the system. Control plane services <b>204</b> can communicate with the service mapping system <b>202</b> via a messaging protocol fabric <b>206</b>. In the example of <figref idref="DRAWINGS">FIG. 3</figref>, the control plane services are demonstrated as including a billing system <b>208</b>, a firmware management service <b>210</b> and a channel map management service <b>212</b>. It is understood that these are examples of some possible services and other services may be implemented in addition to or as an alternative of the services depicted in this example.

Each of the services <b>208</b>, <b>210</b> and <b>212</b> can communicate with any endpoint that is registered with the messaging protocol fabric <b>206</b> including the service mapping system <b>202</b>, for which registration and related advertisement information can be maintained in a service directory of the protocol. The service mapping system <b>202</b> can be implemented in a computing device <b>214</b> in order to provide a service domain proxy, which in this example is demonstrated as S2.domain.com. The device <b>214</b> can itself be a router and communicate with another domain <b>216</b> in the messaging and protocol fabric <b>206</b> such as using a R2R protocol. Additionally or alternatively, the device <b>214</b> can operate as a connection manager and communicate directly with the messaging protocol fabric <b>206</b>, demonstrated as connection <b>221</b>.

The domain <b>216</b> can also include one or more services, a router and a connection manager <b>218</b>. The connection manager <b>218</b>, for example, can connect one or more IP-based endpoint devices with the messaging protocol fabric <b>206</b>. The control plane service or other endpoints within the messaging protocol fabric can communicate with any advertised endpoints in the fabric, including the IP-based endpoints and the services supported by the mapping system <b>202</b> of the device <b>214</b>. The device <b>214</b> can also include a network interface <b>234</b> to provide for communication with a network via the messaging protocol fabric. The network interface <b>234</b>, for example can implement a lower level protocol such as TCP/IP or the like on which the application level messaging protocol fabric <b>206</b> can be implemented.

As an example, the control plane services <b>204</b> can be programmed for explicit communication in the messaging and protocol fabric <b>206</b>, such as programmed to implement XMPP messaging. In other examples, one or more of the control plane services <b>208</b>, <b>210</b> or <b>212</b> can connect to the messaging protocol fabric <b>206</b> via a services connection manager (not shown). Each of the services <b>208</b>, <b>210</b> and <b>212</b>, for example, can utilize a service translation function, such as the function <b>106</b> disclosed with respect to <figref idref="DRAWINGS">FIG. 2</figref>. In order for a given one of the services <b>208</b>, <b>210</b>, <b>212</b> to communicate messages to one or more recipient nodes in the system <b>200</b> via the messaging protocol fabric <b>206</b>, such a service would need to identify each such recipient, such as according to a MAC address or IP address or other unique identifier in the system. The service function (e.g., function <b>106</b> of <figref idref="DRAWINGS">FIG. 2</figref>) would generate a unique service address for an appropriate service operating in the S2.domain.com and a mask to enable the service mapping system of the device <b>214</b> to implement the appropriate translation, routing and distribution of the message, as disclosed herein.

By way of example, the device <b>214</b> can include a presence manager <b>222</b> that is programmed to perform an advertisement function to advertise and register each of the services that it supports in the service domain via corresponding service directory for the messaging protocol fabric <b>206</b>. As disclosed with respect to <figref idref="DRAWINGS">FIG. 2</figref>, unique identifiers for each of the services and corresponding recipient nodes in the system <b>200</b> can be encoded by a corresponding service ID and mask (e.g., by service translation function <b>106</b> of <figref idref="DRAWINGS">FIG. 2</figref>) in response to a request from each of the control plane services <b>204</b>. Additionally, the mask of a corresponding message that is provided by one of the control plane services can also be utilized by the service mapping system <b>202</b> to determine a mode of delivery for the service message to downstream nodes.

For example, the downstream nodes can include one or more control systems <b>224</b> and <b>225</b> demonstrated as control system <b>1</b> through control system M, where M is positive integer denoting the number of control systems. The control systems <b>224</b> and <b>225</b> can be implemented in respective headends of the system <b>200</b>. Additionally or alternatively, the recipient nodes can correspond to endpoint devices <b>226</b> and <b>228</b> associated with each of the respective control systems <b>224</b>. In the example of <figref idref="DRAWINGS">FIG. 3</figref>, control system <b>1</b> is coupled to communicate with N endpoint devices <b>226</b> and control system M can communicate with P endpoint devices, where N and P are positive integers denoting the number of devices associated with each respective control system.

The endpoint devices can be non-IP endpoint devices. As used herein, a non-IP endpoint device refers to a device that is not configured to communicate via the IP messaging and presence protocol. Examples of non-IP endpoint devices include set-top boxes, cable cards, other consumer premises equipment or the like device that implement non-IP messaging protocols. These non-IP endpoint devices are sometimes referred to as legacy devices as they do not encompass newer types of endpoints that are IP-enabled and, in particular, enabled for operation in an IP messaging and presence protocol environment. Instead, such non-IP endpoints communicate using legacy protocols, such as RF based communication (e.g., quadrature amplitude modulation (QAM) or quadrature phase-shift keying (QPSK)) that may encode command and control information (e.g., according to ISO/IEC 13818-6).

Each control system <b>224</b> and <b>225</b> can be coupled to respective endpoint devices <b>226</b> and <b>228</b> through a combiner network <b>230</b> and <b>232</b>. The combiner networks <b>230</b> and <b>232</b> can combine service messages (e.g., from the control plane services <b>204</b>) with other broadcast content that can be sent to the non-IP endpoints <b>226</b> and <b>228</b> via RF modulation (e.g., QAM, QPSK or the like). Thus, while the message content can be broadcast via the combiner network <b>230</b> and/or <b>232</b> and be seen by each non-IP endpoint <b>226</b> and <b>228</b>, only the non-IP endpoint(s) to which the service message was originally addressed will extract the message content and perform the encoded instructions.

In some examples, the endpoint devices <b>226</b> and <b>228</b> can be implemented as CPE, such as legacy set top boxes, cable cards or the like that may communicate command and control data with the control systems <b>224</b> and <b>225</b>, respectively, via RF modulated signals. In other examples, some of the endpoint devices <b>226</b> and <b>228</b> can be implemented as hubs (e.g., distribution equipment) connected to communicate with downstream CPE's. The device <b>214</b> can include control system interfaces <b>242</b> and <b>244</b> for communication between the device and with each control system <b>224</b> and <b>225</b>.

Each control system <b>224</b> and <b>225</b> can selectively control distribution of a given service message to one or more respective endpoints <b>226</b> and <b>228</b> based on the mask in the given message and endpoint mapping data <b>236</b> and <b>238</b> stored (e.g., in memory) on each control system. For example, the service mapping system <b>202</b> can route each service message to one or more control systems based on applying a mask to controller identifying data contained within the service mapping data <b>240</b>. The service mapping system <b>202</b> can employ a corresponding control system interface <b>242</b> or <b>244</b>, according to the service identifier in the service address of the message. This interface can then be used for routing the command and control information to one or more control systems that have been identified. That is, the command and control information can be sent according to a given service interface that is selected based on the service ID of the message's service address. The control system interfaces <b>242</b> and <b>244</b>, for example, can support functionalities that can vary according to the services that are communicating the messages and the appropriate functionalities of the respective control systems <b>224</b> and <b>225</b>. Examples of control system interfaces <b>242</b> and <b>244</b> can include BOSS, PTAPI, BFS API, LOAD PIMS, SFTP or the like, and the device <b>214</b> can support any number and type of such interfaces.

By way of example, the billing system <b>208</b> can prepare and send a message via the messaging protocol fabric <b>206</b> to one or more intended recipient nodes in a service domain, such as the S2.domain.com domain associated with the device <b>214</b>. The IP service address can be constructed for delivery of the message to each one or more intended recipients. For instance, the service address can include a service identifier to uniquely identify a given service interface <b>242</b> or <b>244</b>, which can correspond to the control plane service (e.g., billing) that sent the message. The service address can also include a mask that can be utilized to control appropriate translation and routing and distribution of the message based on applying the mask to service mapping data <b>240</b> for the specified service.

The message can be routed to the device <b>214</b> based on the service address in the messaging and presence protocol fabric <b>206</b>. The service mapping system <b>202</b> can employ service mapping data <b>240</b> to compute an address for each endpoint based on the mask contained in the service address as well as a matching function to compute a mode of delivery for the message to each recipient node identified by the address that is computed. The service mapping system <b>202</b> further can perform translation and distribution of the message to the appropriate interface <b>242</b> or <b>244</b> for communication of the message downstream to one or more control systems <b>224</b> and <b>225</b>. As mentioned above, the service mapping data <b>240</b> can include metadata that identifies each of the control systems and other endpoints to which the message can be communicated by the device <b>214</b> as well as service interfaces <b>242</b> and <b>244</b> based on the service identifier.

After the control system(s) and mode of delivery have been computed, the message can be translated and communicated via a service interface which employs the appropriate protocols necessary for the successful communication of the message to each of the target control systems <b>224</b> that have been identified by the service mapping system <b>202</b> as recipient nodes. Each of the control systems <b>224</b> and <b>225</b> can include endpoint mapping functions <b>236</b> and <b>238</b> that can control delivery of the message according to the selected delivery mode. As disclosed herein, the delivery mode can be computed based on the mask and the mapping data such as to indicate a unicast address to a given control system <b>224</b>, a hostcast address to a selected endpoint <b>226</b> or <b>228</b> or a multicast distribution to a selected group of endpoints <b>226</b>-<b>228</b>. As an example, a group of endpoints can correspond to a hub that can communicate with a plurality of respective endpoints as disclosed herein.

In view of the foregoing structural and functional features described above, an example method will be better appreciated with reference to <figref idref="DRAWINGS">FIG. 4</figref>. While, for purposes of simplicity of explanation, the method is shown and described as executing serially, it is to be understood and appreciated that such method is not limited by the illustrated order, as parts of the method could occur in different orders and/or concurrently from that shown and described herein. Such method or portions thereof can be implemented as instructions stored in a non-transitory storage media as well as be executed by a processor of a computer, for example.

<figref idref="DRAWINGS">FIG. 4</figref> depicts an example of a method <b>300</b> that can be utilized (e.g., by a mapping system) for controlling routing and distribution of a message. The method begins at <b>302</b> in which a message is received. The message can include a service address such as a well formed address construct for routing in a messaging and presence protocol, as disclosed herein.

At <b>304</b>, a determination is made as to whether a service ID specified in the service address of the message is configured for further processing. That is, does the service ID correspond to valid service supported by the mapping system? If the service ID is not configured, the method proceeds to <b>306</b> to respond with an error and the method can end. If the service ID specified in the address is configured, the method can proceed to <b>308</b>. At <b>308</b>, a determination is made as to whether a mask in the service address matches one or more controller IDs. For example, the mask can match a given one of the controller IDs exactly or it can match multiple controller IDs. If the mask matches one or more controller IDs, the method can proceed to <b>310</b> for translating the message and forwarding it to each identified controller for which the match was found. The match can be determined as disclosed herein based on applying the mask to the controller ID for each controller that is identified for the service determined at <b>304</b>. The translated message can be best routed to a given controller in the system based on application of the mask to the controller identified such as stored in the associated mapping data.

If the mask does not match at <b>308</b>, the method can proceed to <b>312</b>. At <b>312</b>, a determination is made as to whether the mask matches a host identifier on a controller's network. If the mask matches a host identifier provided on a given controller's network, the method can proceed to <b>314</b> in which the message is translated and forwarded to the identified host via the specified controller. For example, the host can correspond to a downstream endpoint device, such as a CPE or the like.

If the determination at <b>316</b> is negative, the method can proceed to <b>320</b> for another determination. The determination at <b>320</b> evaluates and applies the mask to each controller ID to determine if a match exists between the mask and all the downstream controller nodes. For example a mask can be established such that application of the mask (e.g., the bitwise operation) results in identifying each controller that may reside downstream from the mapping system implementing the method. If such a broadcast match exists, the method proceeds to <b>322</b> and the message can be translated and forwarded to each of the controllers, thereby effecting a broadcast distribution to such controllers.

Each controller that receives the translated message can further analyze the mask that is provided in the message relative to a predetermined data structure (e.g., endpoint mapping data <b>236</b> and <b>238</b>). The data structure can be applied to the mask for determining distribution of each respective service message based on matching mask values to different broadcast service groups specified in the data structure. For example, broadcast service groups can correspond to groups of endpoints residing downstream from the controller. The data structure can provide a table (e.g., a look-up table) programmed to determine downstream distribution of message content in response to the mask that was specified in the message received by the mapping system. In some examples, the message can include a mask that results in its broadcast to all broadcast service groups such that the message will be distributed to each and every endpoint downstream from the controller. It is to be understood that a broadcast service group can include one or more specified downstream nodes, which can include endpoints or groups of endpoints. In other examples, the mask can contain a value that does not represent a further distribution from the control system to endpoints such that the controller itself will consume the message such as for implementing command and control instructions provided by a service or other endpoint in the messaging and presence protocol fabric.

<figref idref="DRAWINGS">FIG. 5</figref> depicts an example of another method <b>400</b> that can be implemented. At <b>402</b>, the method includes receiving a message at device (e.g., the mapping system <b>10</b> of <figref idref="DRAWINGS">FIG. 1</figref>, device <b>134</b> of <figref idref="DRAWINGS">FIG. 2</figref> or device <b>214</b> of <figref idref="DRAWINGS">FIG. 3</figref>) via a messaging protocol based on a service address of the message. As disclosed herein the message includes a service address and a mask, which enable the message to be received at a message service of the device. There can be any number of such services that can receive messages via the messaging protocol.

At <b>404</b>, the mask can be applied to mapping data to determine one or more recipient nodes for the message. The mapping data can specify a location for each of the plurality of nodes as well as specify service interfaces operative to provide the message to each of the plurality of nodes. For example, a network address for each of the plurality of nodes can be computed (e.g., by address calculator <b>24</b> of <figref idref="DRAWINGS">FIG. 1</figref>) based on applying the mask to respective identifiers stored in the mapping data for each of the plurality of nodes. A matching function (e.g., matching function <b>26</b> of <figref idref="DRAWINGS">FIG. 1</figref>) can also apply the mask to each computed network address to determine if a match exists and thereby control delivery of the message to the at least one recipient node.

At <b>406</b>, a service interface can be selected for the message based on a service identifier in the service address. For example, a corresponding service interface may be provided for each service supported at the device for delivery of the messages sent to such service. At <b>408</b>, the message can be sent to the at least one recipient node using the selected service interface.

In some examples, prior to sending the message to recipient nodes, the message can be translated (e.g., by translation function <b>28</b> of <figref idref="DRAWINGS">FIG. 1</figref>) to provide a translated version of the message for delivery to the at least one recipient node. Additionally, a protocol adapter (e.g., the adapter <b>32</b> of <figref idref="DRAWINGS">FIG. 1</figref>) can be configured to convert the translated message to a protocol-adapted message based on the mapping data. The protocol-adapted message thus can have a format to enable delivery to the at least one recipient node (e.g., an RF delivery protocol or the like) which can depend on the protocol utilized for communication with respect to each node.

As disclosed herein, in some examples, the recipient nodes for the message can be implemented as a plurality of controllers (e.g., control systems <b>224</b> and <b>224</b> of <figref idref="DRAWINGS">FIG. 3</figref>) in a cable television system. Each controller can service a plurality of downstream nodes (e.g., CPE or the like—nodes <b>226</b> and <b>228</b> of <figref idref="DRAWINGS">FIG. 3</figref>). Groups of selected downstream nodes can further be arranged into predetermined service groupings (e.g., broadcast service groups), such as can be physical or logical groupings of nodes. The mask thus can be programmable to identify each of the service groupings or at least a subset of the plurality of downstream nodes, such that distribution of the message to each of the controllers can be controlled according to the mask. The mask can be employed by each of the controllers to control further downstream distribution from each recipient controller to nodes located downstream relative to such controller(s).

Examples of Mapping for Routing and Distribution of Messages

The following example will illustrate the service masks and addressing for routing and distribution of messages via an application level messaging protocol. This example uses 4 bytes for controller.id and as an illustration uses Class C IP address and Classless Inter-Domain Routing (CIDR) notation. It is understood that this is for purposes of an example, only and that, in practice, the controller.id can be any number of bytes, and a given recipient node can be different than a controller.

Service Mapping Metadata

In this example each recipient node can be uniquely identified by a controller ID, which in this example is shown in both a dotted decimal value and a corresponding to a 32 bit word in a dotted octal format. Each controller ID can be stored in service mapping data (e.g., mapping data <b>16</b> of <figref idref="DRAWINGS">FIG. 1</figref> or mapping data <b>240</b> of <figref idref="DRAWINGS">FIG. 3</figref>. In the following table it is assumed that there are four controllers for a given service (service S1) and that a 28 bit subnet mask, corresponding to 28 most-significant bits designed to identify one or more of the controllers based on applying a mask from a service address of a message as disclosed herein.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="273pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 1</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Service Domain: example.com</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="21pt" align="left" /><colspec colname="2" colwidth="126pt" align="left" /><colspec colname="3" colwidth="126pt" align="left" /><tbody valign="top"><row><entry>Svc</entry><entry>controller.id</entry><entry>controller.mask (/28)</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>S1</entry><entry>192.168.1.1</entry><entry>255.255.255.240</entry></row><row><entry /><entry>11000000.10101000.00000001.00000001</entry><entry>11111111.11111111.11111111.11110000</entry></row><row><entry>S1</entry><entry>192.168.1.17</entry><entry>255.255.255.240</entry></row><row><entry /><entry>11000000.10101000.00000001.00010001</entry><entry>11111111.11111111.11111111.11110000</entry></row><row><entry>S1</entry><entry>192.168.1.33</entry><entry>255.255.255.240</entry></row><row><entry /><entry>11000000.10101000.00000001.00100001</entry><entry>11111111.11111111.11111111.11110000</entry></row><row><entry>S1</entry><entry>192.168.1.65</entry><entry>255.255.255.240</entry></row><row><entry /><entry>11000000.10101000.00000001.01000001</entry><entry>11111111.11111111.11111111.11110000</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The metadata provided above in Table 1 can be translated into following addresses shown in Table 2, which include a controller ID using a CIDR notation, a network address for each controller. Also shown for each controller are a broadcast address (in dotted decimal and binary notations) and an IP range for a given subnet. In this example, it is assumed that each controller and associated subnets are part of a given service (e.g., service S1 from Table 1). The broadcast address can be one or more predetermined unique identifiers for each controller that specifies a mask value that is to be broadcast, for example. The IP subnet range can be used to specify different nodes in the subnet supported by each controller to which the message can be distributed based on a given mask provided in message's service address. Different unique masks can be assigned to different predetermined broadcast groups of nodes, such that each unique mask can be interpreted by a controller to effect routing to a specified broadcast group.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="56pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="126pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 2</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Controller using</entry><entry>Network</entry><entry /><entry>IP range</entry></row><row><entry>CIDR notation</entry><entry>Address</entry><entry>Broadcast Address</entry><entry>in subnet</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>192.168.1.1/28</entry><entry>192.168.1.0</entry><entry>192.168.1.15</entry><entry>192.168.1.1</entry></row><row><entry /><entry /><entry>11000000.10101000.00000001.00001111</entry><entry>to</entry></row><row><entry /><entry /><entry /><entry>192.168.1.14</entry></row><row><entry>192.168.1.17/28</entry><entry>192.168.1.16</entry><entry>192.168.1.31</entry><entry>192.168.1.17</entry></row><row><entry /><entry /><entry>11000000.10101000.00000001.00011111</entry><entry>to</entry></row><row><entry /><entry /><entry /><entry>192.168.1.30</entry></row><row><entry>192.168.1.33/28</entry><entry>192.168.1.32</entry><entry>192.168.1.47</entry><entry>192.168.1.33</entry></row><row><entry /><entry /><entry>11000000.10101000.00000001.00101111</entry><entry>to</entry></row><row><entry /><entry /><entry /><entry>192.168.1.46</entry></row><row><entry>192.168.1.65/28</entry><entry>192.168.1.64</entry><entry>192.168.1.79</entry><entry>192.168.1.65</entry></row><row><entry /><entry /><entry>11000000.10101000.00000001.01001111</entry><entry>to</entry></row><row><entry /><entry /><entry /><entry>192.168.1.78</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

In view of the example information in Tables 1 and 2, routing examples are provided below to demonstrate how a message having a service address can be routed to one or more controllers and interpreted by recipient controls for downstream distribution, as provided by the mask. In these examples, the service addresses are provided in the form SERVICE_ID@domain/mask, such a can be well formed address construct for a messaging and presence protocol (e.g., a JID for XMPP) as disclosed above.

Example 1

service address: S1@example.com/192.168.1.1

This message will be routed only to the controller with a controller.id=192.168.1.1 because the mask 192.168.1.1 exactly matches the controller ID in table 2. This can be determined, for example, by bitwise ANDing the controller mask with the each controller ID for service S1 in Table 2.

Example 2

This example further demonstrates how a given controller can interpret the mask in a message routed to it for distribution of the message to a specific part of the network. For example, the controller can be programmed to include endpoint mapping data (e.g., endpoint mapping data <b>236</b> and <b>238</b> of <figref idref="DRAWINGS">FIG. 3</figref>) programmed to map the mask into a corresponding one of a plurality of broadcast service groups, such as shown in Table 3. Each controller or other device can include a similar data structure for use interpreting a mask provided in a service address to effect distribution of the message to nodes belonging to an identified group.

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE 3</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Controller CIDR = 192.168.1.1/28</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="84pt" align="left" /><colspec colname="2" colwidth="98pt" align="left" /><tbody valign="top"><row><entry /><entry /><entry>Broadcast Service</entry></row><row><entry /><entry>Mask</entry><entry>Group (BSG)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>192.168.1.2</entry><entry>BSG-1</entry></row><row><entry /><entry>192.168.1.3</entry><entry>BSG-2</entry></row><row><entry /><entry>192.168.1.4</entry><entry>BSG-3</entry></row><row><entry /><entry>192.168.1.5</entry><entry>BSG-4</entry></row><row><entry /><entry>192.168.1.0</entry><entry>All BSG</entry></row><row><entry /><entry>192.168.1.15</entry><entry>All BSG</entry></row><row><entry /><entry>192.168.1.31</entry><entry>All BSG</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> In view of table 3, given a service address of S1@example.com/192.168.1.3 in a message, the message will be routed only to the controller with controller.id=192.168.1.1 based on applying the mask to the controller IDs of Table 2. The controller further is configured to map it to BSG-2 based on using the mask to evaluate endpoint mapping data of the controller (e.g., Table 3) in which the mask in the service matches the index value for BSG-2

Example 3

This example illustrates sending multicast maskcast messages to a proper subset of controllers. Thus, given a service address S1@example.com/192.168.1.31, the mask value of 192.168.1.31 is converted to a binary representation (11000000.10101000.00000001.00101110) and applied (e.g., via bitwise operation by the mapping logic <b>14</b> of <figref idref="DRAWINGS">FIG. 1</figref>) to controller IDs stored in service mapping data associated with service identifier S1 (e.g., as provided in Table 2) to determine which (if any) controller IDs match the mask. In this case, the mask matches and will be routed to the controller with controller.id=192.168.1.1 and also to controller.id=192.168.1.17. The message is translated and forwarded to each of these controllers using the service interface corresponding to service identifier S1. Each of these controllers will identify that this is a broadcast message meant for all the BSG based on the value of the mask and forward it to all BSG.

Example 4

A broadcast service message to all controllers can be sent (e.g., by a control plane service) using a mask that encompasses all controllers. In the example of the controllers of Table 2, a service address of S1@example.com/192.168.1.127 thus would be sent via a corresponding service interface to each of the controllers.

Example 5

This example demonstrates how the messages can be sent to controllers having controller IDs 192.168.1.33 and 192.168.1.65, but not to the controllers having controller IDs 192.168.1.1 and 192.168.17. This can be accomplished for the example controller IDs of Table 2 by providing the message with a service address of S1@example.com/192.168.1.96. Since the mask does not correspond to a specified BSG in Table 2 for either controller, the controller can be configured to consume the message, such as by programming itself based on the content in the message payload, for example.

What have been described above are examples. It is, of course, not possible to describe every conceivable combination of components or methods, but one of ordinary skill in the art will recognize that many further combinations and permutations are possible. Accordingly, the invention is intended to embrace all such alterations, modifications, and variations that fall within the scope of this application, including the appended claims.

Where the disclosure or claims recite “a,” “an,” “a first,” or “another” element, or the equivalent thereof, it should be interpreted to include one or more than one such element, neither requiring nor excluding two or more such elements. As used herein, the term “includes” means includes but not limited to, the term “including” means including but not limited to. The term “based on” means based at least in part on.