Patent Application
20160234072
A service provider network (such as a data network) may include a number of multicast trees for delivering content such as video and/or audio data to various users. Any given multicast tree in the network may include one or more content receivers operably coupled to one or more routers and one or more transmission sources. The receivers, routers, and transmission sources may be coupled to each other via links (e.g., wireless and/or wired links, such as optical fiber links), which may span large distances. The transmission source may transmit content as one or more data streams to the routers via the links. The routers, in turn, direct the data stream over the links to other routers or various receivers. Thus, a multicast tree defines one or more paths extending from a source to one or more receivers.
The size of the multicast trees may be large and may continue to grow with the advent of new or additional services, such as switched digital video (SDV). SDV networks are known to dynamically transmit only a subset of available video streams, based on which of the video streams are selected by the users at any given time. Where a network is designed to multicast content to large numbers of users spread across large geographical regions, it is not unusual for the network to contain thousands of different multicast trees at any given time. In general, the larger a network becomes, the more challenging it is to for service providers to maintain and/or troubleshoot the network.
When troubleshooting errors that may be present in multicast trees within a network, it may be useful for a service provider (e.g., a service technician) to search the multicast trees of one or more networks for certain attribute characteristics. The attributes may relate to, e.g., the structure of the multicast trees and/or the data being transmitted by the multicast trees.
The types of searches that service technicians may want to perform in the network may include, for example, but are not limited to, (i) determining which one or more multicast groups are sourced from a particular source, (ii) determining which one or more multicast groups arrive on a particular interface of a router and/or on a particular router, (iii) determining which one or more multicast trees carry a particular service (e.g., a particular video stream or other data stream), and (iv) determining those one or more multicast groups in which the packet per second rate as measured by routers in the associated multicast trees differs by a predetermined configurable amount. It may also be desirable and helpful to generate and display a visual rendering of an electronic representation of one or more of the multicast trees in the network. Accordingly, various illustrative methods, systems, and software are disclosed for, e.g., receiving data from each of a plurality of components in a network, the components being arranged as a plurality of multicast trees, the data from each of the components indicating a structure of a portion of the network and at least one attribute associated with the respective component. Further the disclosure provides for determining, based on the data, a structure of at least some of the multicast trees, receiving search criteria, and determining which of the multicast trees meet the search criteria, based on the attributes associated with the components and the determined structure.
Also, various illustrative methods, systems, and software are disclosed for determining, based on a plurality of data messages, a structure of a plurality of multicast trees in a network that comprises a plurality of components, each of the data messages indicating a structure of a different portion of the network and at least one attribute associated with at least one of the components of the network, and determining which of the multicast trees meet search criteria, based on the attributes and the determined structure.
As another example, illustrative systems are disclosed, that comprise a computer configured to receive a plurality of data messages from a network, the network comprising a plurality of components arranged as a plurality of multicast trees, each of the data messages indicating a structure of a different portion of the network and at least one attribute associated with at least one of the components of the network; and a non-transitory computer-readable medium. The computer may be configured to determine, based on the plurality of data messages, a structure of at least some of the multicast trees, store, in the non-transitory computer-readable medium, a logical representation of the determined structure of the at least some of the multicast trees, and determine which of the multicast trees meet search criteria, based on the attributes and the stored logical representation.
These and other aspects of the disclosure will be apparent upon consideration of the following detailed description.
Illustrative embodiments may be best understood by referring to the following detailed description in conjunction with the accompanying drawings, in which:
One or more of the illustrative embodiments as described herein may generally provide a system, software, and method for generating a logical representation of multicast trees in a data network. Such a data network may comprise sources, routers and receivers logically arranged as one or more multicast trees to transmit and provide content such as data, and/or such as audio and/or video (A/V) data. The data may be transmitted in the form of one or more data streams. The data may comprise, for instance, time-sensitive data such as any kind of streamed data, to various users. Each multicast tree may provide such data to a particular geographical region and may be characterized by various attributes. Using illustrative systems disclosed herein, a user may be able to search the attributes of each multicast tree. For example, a user may search the service network to determine which multicast trees in the network share one or more attributes. Such a capability may, among other things, assist the user in assessing or troubleshooting various issues that affect the transmission of the data within the network to the user (e.g., customer).
For any given network, a service provider may provide various types of content to the plurality of multicast trees 12. Each multicast tree may be designated to transmit the content (e.g., A/V data) to, for example, receivers in a specific geographical region within a particular country. Each multicast tree 12 may include at least one transmission source 16 (e.g., multicast tree 12a has source 16a, multicast tree 12b has source 16b, . . . and multicast tree 12n has source 16n). The transmission source 16 for a given tree may be adapted to generate the content data, which may comprise a plurality of packets. In the case of A/V data, each packet may include video or audio data (or both).
The data (e.g., A/V data and/or other data) may also include control information to instruct elements in the multicast tree 12 (e.g., the routers 18), for example, how to control the flow of the data to a particular receiver 20 (e.g., a user device). In one example, the control information may correspond to data that is sent to a particular receiver 20 to enable various services. For example, the control information may identify a command to cause the particular receiver 20 to receive and visually present HBO programming in the event the user decides to view HBO programming, or to add HBO programming to his/her existing service plan.
A plurality of routers 18a-18m may be configured to receive the data from each source 16a-16n, respectively, and to forward the received data to a next component in the associated path of the multicast tree. A plurality of receivers 20a-20p are coupled to the routers 18a-18m via links 19 (e.g., wired and/or wireless links). In the illustrated example, each tree 12a-12n includes one or more receivers 20a-20p and one or more routers 18a-18m, where each of n, m, and p may be any number equal to or greater than one, and may be the same or different numbers from each other. Also, the numbers of receivers and routers may be different for each of the trees 12. In the illustrated example, the router 18a of tree 12a directs the data to the receiver 20a, and the router 18n of tree 12a directs the data to the receivers 20b and 20p. The receivers 20a-20p are configured to present the data to an end user (e.g., the customer), such as on a display (e.g., television set, mobile device, or monitor) for viewing, and/or to a memory such as a hard drive or other computer-readable medium for storage. The source 16a, routers 18a-18m, and receivers 20a-20p may comprise multicast components within the multicast tree 12a and may cooperate with each other to transmit the data to the appropriate receivers 20. In general, all references made specifically to the multicast tree 12a or any portion thereof may apply to any of the multicast trees 12b-12n or any portion thereof. For example, each multicast tree 12b-12n may include any number of multicast components such as a transmission source, routers, and receivers. It is understood that each multicast tree 12a-12n may include different or equal numbers of sources, routers, and receivers from one another, and may or may not overlap such that they share at least some of the same sources, routers, links and/or receivers. Further, the particular arrangement of the sources, routers, and receivers may vary or be similar to one another for each multicast tree 12a-12n.
Multicast components (e.g., 16, 18a-18m, and 20a-20p) in the multicast trees 12a-12n may be communicatively coupled together either directly or indirectly, such as via a plurality of links 19a-19q, which may be implemented at the physical layer as, e.g., electrical, electromagnetic, and/or optical connections. Any of links 19a-19q may be wired or wireless links. With respect to the example multicast tree 12a, for example, the source 16a and the router 18a are coupled together via the link 19a, the router 18a and the receiver 20a are coupled together via the link 19b, the source 16a and the router 18n are coupled together via the link 19c, the router 18n and the receiver 20b are coupled together via the link 19d, and the router 18n and the receiver 20n are coupled together via the link 19q. In general, multicast components may transmit the data originating from the respective source 16 to the next multicast component downstream in the trees 12a-12n via a corresponding one of links 19.
The coupling of each receiver 20 to the source 16 via a particular router 18 (and multiple links 19) is referred to herein as a path. In the simplified example of
A plurality of attributes 14a-14n are associated with the multicast trees 12a-12n, and these attributes may be stored as data such as in a database. Each attribute 14a-14n may identify one or more characteristics of the multicast trees 14, or any portion thereof. Furthermore, some or all of the attributes 14 may be associated with various particular geographic regions. For example, the attributes 14a may identify one or more characteristics with respect to the data in multicast tree 12a whose viewers are situated in Grand Rapids, Mich. Such identified characteristics may include, for instance, one or more channel types (e.g., ESPN, HBO, etc.), a particular type of video encoding (e.g., high definition or standard definition, MPEG2/MPEG4), transmission rules (e.g., local events such as, but not limited to, televised athletic events of interest to subscribers in the Grand Rapids area, and content which has been processed to include commercials of merchants local to the Grand Rapids area, etc). The attributes 14a for a given multicast tree or portion thereof may also include, for example, an identification as to whether the data in that multicast tree is (i) variable bit-rate encoded or constant bit-rate encoded, (ii) a single program transport stream (SPTS) or a multiple program transport stream (MPTS), and/or (iii) encrypted (and if so, an identification of the type of encryption used). It is contemplated that the other such attributes 14b-14n may each identify characteristics with respect to the A/V data and/or other data for multicast trees 12b-12n, respectively, and may identify any one or more of the items discussed herein in connection with the attributes 14a.
The server 52 may implement (such as in software) a correlation engine 62 that communicates with the routers 18a-18m within each multicast tree 12a-12n via the first communication link 55. Each router 18a-18m includes one or more interfaces for receiving incoming multicast packets of data and for transmitting outgoing multicast packets of data. The correlation engine 62 may receive an identification data message from each router 18, in which the identification data may identify which interface of the respective router 18 is an incoming interface (e.g., an interface that receives data, such as a physical or logical data port) and/or which interface is an outgoing interface (e.g., an interface that transmits data, such as a physical or logical data port). A given interface may also be a bi-directional interface that can both receive and transmit data. Thus, the identification data from each of the routers 18a-18m represents a local view (or perspective) of the multicast tree 12 of which it is a part, from the point of view of the respective router. These local views, each representing a relatively small portion of the multicast tree structure, may be combined, e.g., connected, together to form a representation of entire multicast tree structure (or at least of a greater portion of the multicast tree structure). The correlation engine 62, which may be configured to form a representation from the plurality of local views, is also configured to periodically query each of the routers 18a-18m in any given multicast tree 12a-12n so that each router 18a-18m transmits, in response, the respective identification data. In one example, the correlation engine 62 may query each of the routers 18a-18m every X time period (where X may be, for example, 20 minutes or less, or between twenty minutes and two hours, or greater than two hours) so that each router 18a-18m in response to the query transmits the identification data. In some embodiments, the queries may be made one at a time for each of the routers. In other embodiments, the queries may be made in parallel to multiple ones of the routers simultaneously. Queries may be conducted at, for example, random or pre-specified time intervals. The particular time interval used to query the routers 18a-18m may be user-selectable (or automatically selected) depending upon the desired criteria of a particular implementation, the size of network 10, and/or the expected size and/or number of multicast trees 12. Additionally or alternatively, the routers 18a-18m may transmit the identification data spontaneously (e.g., periodically) and not necessarily responsive to a query. In either case, the identification data may be sent directly to server 52 and/or via an intermediate device that collects the identification data and provides information from the received identification data to server 52.
The correlation engine 62 may assemble the local views determined from the information provided by the identification data from each router 18a-18n into a single end-to-end logical representation (e.g., from source to receiver across each path) for some or all of multicast trees 12a-12n. In response to generating the logical representation for each multicast tree, the correlation engine 62 may determine the number of packets lost in those paths, such as due to network errors. Such packet loss may cause the occurrence of video tiling that may impair the visual data at one or more of the receivers 20a-20p.
The routers 18a-18m in this example may be configured to provide the identification data by executing, for example, a protocol independent multicast (PIM) and an internet group membership protocol (IGMP). IGMP is a known signaling protocol that may be used by any one or more of the receivers 20 to express interest in a particular multicast group to a corresponding router. The routers 18a-18m may also use PIM in a known way to build the respective multicast tree 12 from the receivers 20 back to the transmission source 16.
Each router 18 may also be configured such that the identification data includes data regarding various attributes 14, such as data identifying the multicast stream packet rate as reported by each respective router. The packet rate may be represented in units of, e.g., packets per second (pps). Each router 18 may compute the packet rate over a sliding window, such as a window of a less than three seconds in length, or longer. The server 52 may query each router 12 for such information. In theory, for a constant bit rate (CBR) source 16, it would be expected that all routers 12 receiving data from that source 16 would report similar packet rates in the same multicast tree 12. If there is a significant difference in the packet rates reported by the routers 12, then such a condition may indicate one or more points in the network 10 where a problem may exist. For instance, if a router reports 1000 pps and another router downstream from that router in the same path of a multicast tree reports 0 pps, such a condition may be indicative of an issue between those two routers. This condition may be interpreted to mean that devices and subscribers downstream of the condition have lost access to the A/V content. More subtle differences in packet rate information across routers in a multicast tree could indicate other network problems that result in poor A/V quality.
Correlation engine 62 may generate the logical representation by piecing together the local views from the various routers 18 into a larger logical end-to-end picture. The logical representation may be represented in any manner desired. For example, the logical representation may include at least the following information (which will be discussed further below):
In the above example, the first value in each parentheses represents a source IP address and the second value in each parentheses represents a multicast destination group IP address. Together, this pair of IP addresses identities a multicast tree. For instance, one multicast tree listed above is identified as the pair 69.141.129.194, 232.137.16.16, and another multicast tree listed above is identified as the pair 69.141.180.130, 232.196.38.1. In this example, there may be multiple entries for each multicast tree, each entry representing a different path in the multicast tree. The illustrative logical representation as shown above also includes an ordered series of router interfaces (indicated in { } brackets, such as “{Gig1/14}”) and routers (such as “ur01.albuquerque.nm.albuq”). This ordered list indicates the direction and location of each path in the multicast trees. Of course, the logical representation may be represented in any manner desired, as long as the logical representation contains desired information about multicast tree structure.
In addition to the above information, correlation engine 62 may cause the logical representation to further include or otherwise be associated with the various attributes 14 represented by the received identification data. Thus, one or more of the attributes 14 may be associated with any of the routers and/or paths in the logical representation of the multicast trees.
The database 54 may store the logical representation of the multicast tress and/or the information identifying or otherwise representing the attributes 14 as collected by correlation engine 62. Alternatively or additionally, data identifying or otherwise representing the attributes 14a-14n may be stored locally at a corresponding one or more of the sources 16. In such a case, when performing a search, the server 52 (e.g., using a search engine 64, as discussed below) may actively pull the attributes 14 from the sources 16, rather than from the database 54. In either case, the attributes 14 may be stored in such a manner that they are associated with, or can otherwise be correlated to, the multicast trees or portions thereof having the respective attributes 14.
The server 52 may also implement search engine 64 to search the stored attributes based on various search criteria, and to return results of the search with and identification of which of the multicast trees 12 or portions thereof meet the search criteria. The user may access the search engine 64 to enter the search criteria via the client 58. For example, the user may access a URL via an internet connection (or through one or more other public and/or private networks) with the client 58 and enter data corresponding to the various search criteria that is provided to the search engine 64. Responsive to receiving the search criteria, the search engine 64 may search through the attributes 14 (which may be stored in database 54) to locate those multicast trees and/or portions thereof having the attributes 14 that meet the search criteria.
The following are non-limiting examples of search criteria and/or queries that may be searched on:
As can be seen above from the large variation in the types of example searches that may be performed, the search capability provided by the system 50 may be used in connection with troubleshooting many different types of quality issues involving the delivery of A/V and/or other data to various users. For example, in the event an issue is reported with the delivery of A/V data on the NICKELODEAN channel in a particular city or other particular geographical region, a user may use the search engine 64 to determine which multicast groups carry some or all of the NICKELODEAN feeds into that city or other geographical region. The server 52 may transmit an indication all of the multicast trees 12 that carry the NICKELODEAN feed (e.g., either pre-splice or post-splice feed) into the specified city or other geographical region to the client 58 for visual presentation to the user. The server 52 may also present data to the client 58 corresponding to whether there is any packet loss that is being exhibited within the multicast trees of the multicast group while providing the NICKELODEAN feed.
As can also be seen from the above example searches, the search capability provided by the system 50 may be able to, for instance, take identification data for one or more of the components and use that as part of the search criteria, such that the search criteria specifies a particular one or more of the attributes associated with a particular one or more of the components: e.g., determine all multicast trees that ingress through the a particular interface on a particular router, or, determine all multicast trees that are sourced onto a particular router and that have a receiver on another particular router. As another example, the system 50 may be able to take the identification data for various routers and search for quantitative differences, such that the search criteria specifies a particular quantitative difference between attributes associated with different ones of the components: e.g., determine all multicast trees where the packet rate across routers differs by at least a predetermined value (e.g., differs by 10 pps or more). This latter type of search may be useful, for instance to determine which router may be experiencing overflow, and in response to the search, the system 50 may compute the delta between the various router pps values and report a particular multicast tree if the multicast tree's delta values exceed the search criteria value.
As also seen in some of the above examples, searches may involve criteria that specify a particular path structure, such as one or more particular components, interfaces, sources, tree hierarchy level (e.g., whether a particular router should be the first, ith, or last router in a path). For example: determine all multicast trees with a particular source IP, or determine all multicast trees that are received by a particular router on a particular interface. These types of searches may be possible because the structure of the multicast trees (including the paths) may be logically constructed from the identification data as described herein.
Searches may additionally be performed with criteria that are not related to the attributes 14 provided by the routers. In such a search, the system 50 may compare at least a portion of the search criteria with one or more of the attributes 14 and/or compare at least another portion of the search criteria with information not represented by any of the attributes. For example, if a router is not aware of which particular content is being carried by that router (e.g., ESPN versus ABC), then such information may be stored and obtained separately from the identification data, and the search criteria may include a specified content: e.g., determine all multicast trees carrying a particular service (e.g., ESPN) and in which groups are received at a particular location.
The above searches are examples and are not intended to limit the scope of the search capability provided by the system 50. In general, searches may be performed on any combination or subcombination of various search criteria, including but not limited to criteria specifying a particular source, multicast group, router, hop, link, router interface (ingress and/or egress), receiver, packet rate range, data rate, geographical region, service, network, error rate (e.g., lost packet rate), cumulative errors, and/or port number.
The results of a search request may be presented as, for instance, one or more internet protocol (IP) addresses that are viewable in a web-based format when selected by the user. However, other search result formats may be used. The results may include an identification of at least a portion of the components (e.g., 16, 18, and/or 20) in any given multicast tree 12a-12n. The results may be electronically presented to the user in any manner. The presentation of the search results in an IP based address format, as shown in several of the figures, is provided as an example and is not to be construed as the only manner in which the system 50 is capable of presenting the search results.
While the example of
An example block representation of a computer 600 is shown in
Computer-readable media include not only a single non-transitory storage medium or single type of such medium, but also a combination of one or more such media and/or types of media. Examples of a computer-readable medium include, but are not limited to, one or more memories, hard drives, solid-state memory devices, optical discs (such as CDs or DVDs), magnetic discs, and magnetic tape drives.
Such a computer-readable medium 602 may store computer-readable instructions (e.g., software) and/or computer-readable data (i.e., information that may or may not be executable). In the present example, computer-readable medium 602 (such as memory and/or hard drive) may be included in any one or more of the devices discussed herein, such as components 52, 58, 60, 62, 64, and/or 54, and may store computer-executable instructions and/or data used by any of those components. Alternatively or additionally, such a computer-readable medium storing the data and/or software may be physically separate from, yet accessible by, any of the devices discussed herein. For example, with regard to server 52, computer-readable medium 602 may include or otherwise represent the data storage medium of database 54, as well as any other memory, hard drives, etc., used by server 52.
Computer 600 may also include a user input/output interface 603 for receiving input from a user (e.g., via a keyboard 605, mouse, and/or remote control) and providing output to the user (e.g., via a display 606, an audio speaker, and/or a printer). Computer 600 may further include a network input/output interface 604 for communicating with other computers or other types of devices, such as via a network or direct connection. Thus, any communication between components 52, 58, 60, 62, 64, and/or 54, and with users, may be attributed to communication via the network input/output interfaces 604 and/or user input/output interfaces 603 of those respective components.
In step 703, in response to the queries, each of the queried devices (e.g., routers 18) returns its respective identification data that may include attributes for that device and/or local view information for that device as discussed previously. The query may specify which attributes are to be included in the identification data. The identification data may be in the form of, e.g., one or more data packets that are in turn logically arranged as messages comprising one or more of those data packets. The data packets may be dedicated to providing the identification data or the packets may also include additional data or other content. As also discussed previously, in alternative embodiments, steps 701 and 702 may be skipped altogether, and instead the identification data may be sent (e.g., periodically) by the devices (e.g., routers 18), even in the absence of a query.
Next, in step 704, the attributes 14 for each device (e.g., router 18) may be extracted (by, e.g., server 52) from the identification data and stored as data in a computer-readable storage medium, such as in database 54. In step 705, server 52 (for example) may also build the logical representation (e.g., the previously-discussed logical representation 10) of the network or of a portion of network, and may store the logical representation in a computer-readable medium, such as in database 54.
The process may also include steps 750-753, which may run independently of steps 701-705. In step 750, a display search screen may be presented (e.g., by client 58), such as the screen shown in
Next, in step 752, a search of the stored attributes may be performed (e.g., by server 52) for the input search criteria, and it may be determined which portions of the network have attributes meeting the search criteria. Correlating this search result with the logical representation 60, for example, server 52 may be able to generate search results in step 753 including an indication of which multicast trees meet the search criteria, and these search results may be passed to client 58 for storage and/or presentation to the user. The search results may be provided, for example, on a screen such as that shown in
Thus, a system, method, and software have been described for collecting attributes about a network as well as the network structure, performing a search on those attributes, and presenting search results correlated to various multicast trees in the network. Such attribute searching may potentially make network troubleshooting easier.
While various illustrative embodiments have been illustrated and described, it is not intended that these embodiments illustrate and describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. For example, while the multicast trees have been described by way of example as multicasting streamed A/V data, the multicast trees may be used to stream or otherwise provide other types of data in addition to or instead of A/V data, such as voice data, text messages, or data files in general.
This application is a continuation of, and claims priority to, U.S. patent application Ser. No. 14/072,901, filed Nov. 6, 2013, which is a continuation of Ser. No. 13/029,485, filed Feb. 17, 2011, now U.S. Pat. No. 8,599,725, which is a continuation-in-part of U.S. patent application Ser. No. 12/049,511, filed Mar. 17, 2008, now U.S. Pat. No. 8,259,594, each of which is hereby incorporated by reference as to its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14072901 | Nov 2013 | US |
| Child | 14848511 | US | |
| Parent | 13029485 | Feb 2011 | US |
| Child | 14072901 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12049511 | Mar 2008 | US |
| Child | 13029485 | US |
