Abstract:
A network monitoring system compares gathered network information with path information. The comparison between gathered network information and path information provides traceability of automatic and dynamic rerouting function of network and makes it possible to understand the relation between root cause and observed problems. The combined monitoring of data plane with control plane enables identification of the original failure point where behavior is changing though routing failure is propagated around. This will allow the identification of network issues that may lead to service outages and impairments as well as alerting of issues affecting customer satisfaction, and is effective to reduce MTTD (Mean Time To Detect)/MTTR (Mean Time To Repair) and increase service availability in all markets.

Description:
BACKGROUND 
       [0001]    Field 
         [0002]    The present disclosure is generally directed to network monitoring systems, and more specifically, to anomaly detection and real time transmission monitoring. 
         [0003]    Related Art 
         [0004]      FIG. 1  illustrates a related art network monitoring system  100  gathering network information. The network monitoring system can include one or more routers  200   a ,  200   b ,  200   c ,  200   d  configured to provide data to a user data statistics collection module  21 . Such data can include the number of packets and octets from routers via SNMP (Simple Network Management Protocol) MIB (Management Information Base), sFlow, NetFlow and so on. User data statistics collection module  21  feeds into user data anomaly monitoring module  22  configured to monitor the data statistics for anomalies. Detected anomalies are sent to the user terminal  10 . 
         [0005]      FIG. 2  illustrates a related art network monitoring system gathering network packets from taps. This system calculates the network information such as latency and jitter as well as the number of packets and octets from collected packets. In this example, there are one or more taps  300   a ,  300   b ,  300   c ,  300   d ,  300   e , and  300   f  providing the network information to a packet analyzing module  31 , which can conduct packet analysis and feed the packet analysis to the user data statistics collection module  32 , and user data anomaly monitoring module  33 . The above network monitoring systems make a judgment on network anomaly by observing the change of the monitored network information. 
       SUMMARY 
       [0006]    Aspects of the present disclosure include a management computer configured to manage a network. The management computer may involve a memory, configured to store anomaly criteria information for the network and path information for the network; and a processor, configured to apply the path information to at least one of data plane packet information and control plane packet information to generate matching information, the matching information comprising first entries from at least one of the data plane packet information and control plane packet information having sources matched to corresponding second entries from the path information having paths corresponding to the sources; and monitor the network for an anomaly based on the matching information and the anomaly criteria information. 
         [0007]    Aspects of the present disclosure further include a method for managing a network, which can involve managing anomaly criteria information for the network and path information for the network; applying the path information to at least one of data plane packet information and control plane packet information to generate matching information, the matching information comprising first entries from at least one of the data plane packet information and control plane packet information having sources matched to corresponding second entries from the path information having paths corresponding to the sources; and monitoring the network for an anomaly based on the matching information and the anomaly criteria information. 
         [0008]    Aspects of the present disclosure further include a non-transitory computer readable medium storing instructions for managing a network. The instructions can involve managing anomaly criteria information for the network and path information for the network; applying the path information to at least one of data plane packet information and control plane packet information to generate matching information, the matching information comprising first entries from at least one of the data plane packet information and control plane packet information having sources matched to corresponding second entries from the path information having paths corresponding to the sources; and monitoring the network for an anomaly based on the matching information and the anomaly criteria information. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0009]      FIG. 1  illustrates a related art network monitoring system gathering network information. 
           [0010]      FIG. 2  illustrates a related art network monitoring system gathering network packets from taps. 
           [0011]      FIG. 3  illustrates an example network. 
           [0012]      FIG. 4  illustrates an example sample utilization for the example network of  FIG. 3 . 
           [0013]      FIG. 5  illustrates a network monitoring system, in accordance with an example implementation. 
           [0014]      FIG. 6  illustrates an anomaly monitoring block, in accordance with an example implementation 
           [0015]      FIGS. 7( a ) and 7( b )  illustrate flow diagrams of target path selection based on packet information and path information, in accordance with an example implementation. 
           [0016]      FIG. 8  illustrates a flow diagram for path information generation, in accordance with an example implementation. 
           [0017]      FIG. 9  illustrates the flow diagram from anomaly monitoring in accordance with an example implementation. 
           [0018]      FIG. 10  illustrates a flow diagram for the multicast service case, in accordance with an example implementation. 
           [0019]      FIG. 11  illustrates a sequence diagram for the multicast service case, in accordance with an example implementation. 
           [0020]      FIGS. 12( a ) and 12( b )  illustrates packet formats, in accordance with example implementations. 
           [0021]      FIG. 13  illustrates a service request diagram for multicast service, in accordance with an example implementation. 
           [0022]      FIG. 14  illustrates a service stream diagram, in accordance with an example implementation. 
           [0023]      FIG. 15  illustrates an integrated multicast routing table, in accordance with an example implementation. 
           [0024]      FIG. 16  illustrates the path information table, in accordance with an example implementation. 
           [0025]      FIG. 17  illustrates an analyzed packet information table, in accordance with an example implementation. 
           [0026]      FIG. 18  illustrates a data plane packet information table, in accordance with an example implementation. 
           [0027]      FIG. 19  illustrates the control plane packet information table, in accordance with an example implementation. 
           [0028]      FIG. 20  illustrates the data plane and path matching table, in accordance with an example implementation. 
           [0029]      FIG. 21  illustrates a control plane and path matching table, in accordance with an example implementation. 
           [0030]      FIG. 22  illustrates an example of anomaly criteria for data plane, in accordance with an example implementation. 
           [0031]      FIG. 23  illustrates an example of anomaly criteria for control plane, in accordance with an example implementation. 
           [0032]      FIG. 24  illustrates a data plane anomaly monitoring table, in accordance with an example implementation. 
           [0033]      FIG. 25  illustrates a control plane anomaly monitoring table, in accordance with an example implementation. 
           [0034]      FIGS. 26 to 30  illustrate various architectural aspects of the complex multicast service case, in accordance with an example implementation. 
           [0035]      FIGS. 31 to 34  illustrate path and routing tables, in accordance with an example implementation. 
           [0036]      FIG. 35  illustrates an analyzed packet information table, in accordance with an example implementation. 
           [0037]      FIG. 36  illustrates the data plane packet information table, in accordance with an example implementation. 
           [0038]      FIGS. 37 to 40  illustrate various aspects of the unicast case, in accordance with an example implementation. 
           [0039]      FIG. 41  illustrates the packet format that is used for session/service construction, in accordance with an example implementation. 
           [0040]      FIG. 42  illustrates an integrated unicast routing table, in accordance with an example implementation. 
           [0041]      FIG. 43  illustrates an analyzed packet information table for unicast, in accordance with an example implementation. 
           [0042]      FIG. 44  illustrates target path information table generated at target path block for unicast, in accordance with an example implementation. 
           [0043]      FIG. 45  illustrates a path information table, in accordance with an example implementation. 
           [0044]      FIG. 46  illustrates a system environment for the mobile service case, in accordance with an example implementation. 
           [0045]      FIG. 47  illustrates a sequence diagram, in accordance with an example implementation. 
           [0046]      FIG. 48  and  FIG. 49  illustrate packet formats, in accordance with an example implementation. 
           [0047]      FIG. 50  illustrates a service request diagram for mobile service, in accordance with an example implementation. 
           [0048]      FIG. 51  illustrates an example service stream diagram, in accordance with an example implementation. 
           [0049]      FIG. 52  illustrates an integrated unicast routing table about the network topology, in accordance with an example implementation. 
           [0050]      FIG. 53  illustrates an analyzed packet information table, in accordance with an example implementation. 
           [0051]      FIG. 54  illustrates a target path information table, in accordance with an example implementation. 
           [0052]      FIG. 55  illustrates a path information table for mobile service, in accordance with an example implementation. 
           [0053]      FIG. 56  illustrates a data plane packet information table for mobile service, in accordance with an example implementation. 
           [0054]      FIG. 57  illustrates an example computing environment upon which example implementations may be applied. 
       
    
    
     DETAILED DESCRIPTION 
       [0055]    The following detailed description provides further details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. 
         [0056]    In related art network system implementations, transmission path routes automatically and dynamically changing by the reasons such as network failure, traffic congestion, etc. and a data transmission of network service keeps appropriate state. A network transmission is continuously provided without problem in the case that automatic and dynamic rerouting function works correctly if network failure occurred. This automatic and dynamic rerouting function makes it difficult to understand the relation between root cause and observed problems. 
         [0057]      FIG. 3  illustrates an example network with sender  210 , receivers  220   a ,  220   b ,  220   c , and various links. In the example of  FIG. 3 , if a failure occurs on the link B, the utilization of link B will be as illustrated in  FIG. 4 . In the example of  FIG. 3 , there are several devices such as routers  200   a ,  200   b ,  200   c ,  200   d  that transmits IP (Internet Protocol) packets based on routing table, sender  210  that sends IP service data and receiver  220  that receives IP service data from sender. Each device has its own device number, and global and link local IP addresses based on the device number, e.g. router  1  at  200   a  has device number “1”, global IP address “2001:db8::1” and link local IP address “fe80::1” on IF 1 , IF 2  and IF 3 . In the case that a failure occurred on the link B, the utilization of link B is changed like  FIG. 4 . In the related monitoring system, this change is detected as the anomaly that needs immediate recovery. However, if the original route e.g. Link A-B-E-G is rerouted to A-C-F-G and the data is transmitted continuously, immediate recovery is needless. In the related art monitoring systems, the change as illustrated in  FIG. 4  is detected as the anomaly that needs immediate recovery. However, if the original route in  FIG. 3  such as A-B-E-G is rerouted to A-C-F-G and the data is transmitted continuously, immediate recovery is not necessary. 
         [0058]      FIG. 5  illustrates a network monitoring system  100 , in accordance with an example implementation. In the network monitoring system  100 , there is target path block  110 , path information block  120 , and anomaly monitoring block  130 . Target path block  110  selects the target paths those are maintained as the path information for anomaly monitoring, and includes target path selecting module  111  and target path information  112 . This selection can be made based on the analyzed packets come from packet analyzing module  101  and/or based on the analyzed routers come from route analyzing module  102 . Path information block  120  maintains the path information of the target paths specified by the target path block  110 , and includes path information generating module  121  and path information  122 . Anomaly monitoring block  130  monitors anomaly by comparing packet information with path information, and includes packet information generating module  131  and anomaly modeling module  132 . 
         [0059]    The analyzed packets created at packet analyzing module  101  are normally generated based on the packets gathered from taps but also be able to generated from the SNMP MIB, sFlow, NetFlow, etc. gathered from routers. The analyzed routes created at route analyzing module  102  are normally generated based on the routes gathered from routers but also be able to generated from the packets related to routing such as IS-IS (Intermediate System to Intermediate System), PIM (Protocol Independent Multicast), etc. gathered from taps. 
         [0060]    The comparison between packet information and path information at anomaly monitoring block  130  provides traceability of automatic and dynamic rerouting function of network and makes it possible to understand the relation between root cause and observed problems. In  FIG. 5 , there is a tap on each link. By comparing the information from two taps beside a router e.g. tap  300   a  and tap  300   b , the difference between incoming and outgoing the router can be monitored. In example implementations, taps may be applied at both ends of each link. For example, there can be two taps on each link, and by comparing the information from two taps on the same link, the difference occurring inside the link, e.g. originated in fiber, optical transport system, etc., also can be monitored. 
         [0061]      FIG. 6  illustrates an anomaly monitoring block  130 , in accordance with an example implementation. There are two types of packets; one is data plane information such as video data, voice data, etc., the other is control plane information such as service request, routing protocol, and so on. Each of data/control plane information generating part  131   a   1 ,  131   a   2  gathers packet information analyzed at the packet analyzing module  101  on each capturing time to generate information of specified duration for anomaly monitoring. Each of data/control plane and path matching part  132   a   1 ,  132   a   2  constructs information along path input from path information block, and each of data/control plane anomaly monitoring part  132   b   1 ,  132   b   2  detects and/or identifies anomaly based on those information and anomaly criteria  132   c . Details are provided for each of the following examples. 
         [0062]      FIG. 7( a )  illustrates flow diagram of target path selection based on packet information, in accordance with an example implementation. The flow can be executed by target path selecting module  111  and starts at S 1101 , wherein analyzed packets are processed at S 1102 . At S 1103 , the flow extracts service request packets that include endpoints of service, and a loop is initiated at S 1104 . At S 1105 , a check is performed as to whether the packets request the starting or stopping of service. If the packets are requesting the starting of service, then the flow proceeds to S 1106  to add new endpoints to target path information, otherwise the flow proceeds to S 1107  to delete old endpoints from target path information. If no such information is provided (Other), the flow proceeds to S 1108  to end the loop for the packet. Thus in the example of  FIG. 7( a ) , if a service requires a service request when the service starts e.g. SIP (Session Initiating Protocol) request, both the source IP address and the destination IP address specifying the starting service are found in analyzed packets including those service request packets. 
         [0063]    The flow of  FIG. 7( a )  can be similarly modified for target path selection based on path information as illustrated in  FIG. 7( b ) . For example, if a service creates path for service when the service starts e.g. MLD (Multicast Listener Discovery) Report, both the source IP address and the destination IP address those specifies the starting service are found in analyzed route as a path change. In such a modification, the route changes that include the endpoint address are extracted, and the changes are analyzed to determine if they are an addition or deletion. For addition operations, new endpoints are added to the target path information. For deletion operations, old endpoints are deleted from the target path information. The flow can be executed by target path selecting module  111  and starts at S 1201 , wherein analyzed routes are processed at S 1202 . At S 1203 , the flow extracts route changes that include endpoints of service, and a loop is initiated at S 1204 . At S 1205 , a check is performed as to whether the route changes are addition or deletions of endpoints of service. If the route change is an addition, then the flow proceeds to S 1206  to add new endpoints to target path information, otherwise the flow proceeds to S 1207  to delete old endpoints from target path information for a deletion. If no such information is provided (Other), the flow proceeds to S 1208  to end the loop for the change. 
         [0064]      FIG. 8  illustrates a flow diagram for path information generation, in accordance with an example implementation. Analyzed routes e.g. routing table is obtained from each router and those information are listed together. The flow starts at S 1301 , wherein analyzed routes S 1302  and target path information S 1304  are processed. At S 1303 , the flow extracts the list of all routes from routers. At S 1305 , the flow extracts list of endpoints from target path information. At S 1306  a loop is initiated for each endpoint of service. For each iteration of the loop, the flow obtains the router neighboring the endpoint and set it as the current router at S 1307 . At S 1308 , the flow initiates a loop for each of the other endpoints of service. During the loop, a check is performed as to whether the current router has a next router to the other endpoint at S 1309 . If so (Yes), the flow proceeds to S 1310  to set the next router as the current router. If not (No), the flow proceeds to S 1311  to end the loop for the other endpoint. At S 1312 , when each of the other endpoints of service is processed, the loop for the endpoint is terminated. When all of the endpoints are iterated, then the flow terminates at S 1313 . 
         [0065]      FIG. 9  illustrates the flow diagram from anomaly monitoring in accordance with an example implementation. The flow begins at S 1401 , wherein analyzed packets S 1402 , Path information S 1404  and anomaly criteria S 1406  are processed. At S 1403 , the flow is configured to extract the list of data/control plane packet information from the analyzed packets of S 1402 . At S 1405 , the flow is configured to extract the list of data/control plane packet information along path from path information S 1404 . At S 1407 , the flow is configured to construct a list of data/control plane packet information based on anomaly criteria from the anomaly criteria of S 1406 . At S 1408 , a loop is initiated for each entry in the list of packet information from the analyzed packets of S 1402 . At S 1409 , a check is performed to determine if the packet information conflicts with the anomaly criteria. If so (Yes) the flow proceeds to S 1410  to provide an alert to the user. Otherwise (No), the flow proceeds to S 1411  to end the packet information loop. When all of the packet information is processed, the loop ends at S 1412 . 
         [0066]    First Example Implementation of Simple Multicast Service 
         [0067]    In an example implementation for facilitating a multicast service case, the architecture of  FIG. 5  can be utilized, and depending on the desired implementation, the target path block  110  can be rendered to be optional, as the multicast routing table may contain information indicative of the effective route that is created when the receiver starts service and deleted when the receiver stops service.  FIG. 10  illustrates a flow diagram for the multicast service case, in accordance with an example implementation. The differences from the flow of  FIG. 8  includes the modification at S 1303 -E 1  wherein the flow extracts list of all multicast routing tables from routers. At S 1305 -E 1  the flow extracts list of all pairs of multicast groups and sources. At S 1306 -E 1  a loop is created for each multicast group and source pair. At S 1307 -E 1   a , the flow obtains leaves of the multicast group and source pair. At S 1308 -E 1  a loop is created for each leaf. At S 1307 -E 1   b , the router is set with the leaf as current router. At S 1309 -E 1  a check is performed to determine if the current router has the upstream router of the multicast group and source pair. If so (Yes), then the flow proceeds to S 1310 -E 1  to set the upstream router as current router. Otherwise (No), the flow proceeds to S 1311 -E 1  wherein the loop is ended for the leaf. When all leaves are processed, the flow proceeds to S 1312 -E 1  to end the loop for the multicast group and source pair. When all multicast group and source pairs are ended, the flow proceeds to S 1313  to end the flow. 
         [0068]      FIG. 11  illustrates a sequence diagram for the multicast case, in accordance with an example implementation. Sender  210  sends multicast stream to neighboring router  200   a  (S 2101 ). When the receiver  220  starts receiving this stream, the receiver sends MLD Report to express this request to neighboring router  200   c  (S 2102 ), and routers  200   c  and  200   b  send PIM Join to create multicast routing table toward upstream neighbors (S 2103   a , S 2103   b ). After these requests reach the router  200   a , the multicast stream is transmitted from sender  210  to receiver  220  (S 2104   a , S 2104   b , S 2104   c , S 2104   d ). 
         [0069]      FIG. 12( a )  illustrates a packet format of MLD Report in accordance with an example implementation. The MLD field in the packet contains a plurality multicast address records. Each record contains a multicast group and a source that indicates target path.  FIG. 12( b )  illustrates a packet format of PIM Join, in accordance with an example implementation. The PIM Join packet contains a plurality of group sets. Each group set contains a multicast group and source that indicates target path. 
         [0070]      FIG. 13  illustrates a service request diagram for multicast service, in accordance with an example implementation. At the flow of S 2102   a   1 , S 2102   b   1  and S 2102   a   2 , the MLD Report as illustrated in  FIG. 12( a )  is transmitted, and the packets sent at the flow at S 2102   a   1  and S 2102   b   1  contain the same multicast group and source, whereas the flow at S 2102   a   2  contains the other multicast group and source. At the flow of S 2103   a   1 , S 2103   b   1  and S 2103   a   2 , the PIM Join as illustrated in  FIG. 12( b )  is transmitted, and the packets sent at the flow of S 2103   a   1  and S 2103   b   1  contain the same multicast group and source that is the same as that of MLD Report at S 2102   a   1  and S 2102   b   1 . Packets sent at the flow at S 2103   a   2  contains the other multicast group and source that is the same as that of MLD Report at S 2102   a   2 . 
         [0071]      FIG. 14  illustrates a service stream diagram, in accordance with an example implementation. The flow at S 2104   a   1 , S 2104   b   1 , S 2104   c   1 , S 2104   d   1  and S 2104   e   1  are a step through of the multicast stream of  FIG. 11 . The multicast group and source is the same as that of the MLD Report of S 2102   a   1  and S 2102   b   1 , and PIM Join S 2103   a   1  and S 2103   b   1  of  FIG. 13 . The flow at S 2104   a   2 , S 2104   b   2  and S 2104   c   2  illustrates the multicast stream of  FIG. 11 . The multicast group and source is the same as that of MLD Report at S 2102   a   2  and PIM Join at S 2103   a   2 , S 2103   b   2  in  FIG. 13 . 
         [0072]      FIG. 15  illustrates an integrated multicast routing table for  FIG. 14  that is generated at route analyzing module  102  in  FIG. 5  by gathering routing tables from each router. For example, items # 1  and # 2  are from Router  1   200   a , items # 3  and # 4  are from Router  2   200   b , item # 5  is from Router  3   200   c , and item # 6  is from Router  4   200   d . Item # 1  shows the route for service stream S 2104   b   1  in  FIG. 14 , # 2  shows the route for service stream S 2104   b   2 , # 3  shows the route for service stream S 2104   c   1 , # 4  shows the route for service stream S 2104   e   1 , # 5  shows the route for service stream S 2104   c   2 , and # 6  shows the route for service stream S 2104   d   1 . The flag LH (Last Hop) indicates that the outgoing interface of that item is a leaf. The flag FH (First Hop) indicates the incoming interface of that item neighboring sender that has the same IP as the source of that item. 
         [0073]      FIG. 16  illustrates the path information table that is generated at path information block  120  in  FIG. 5  by utilizing the flow diagram of  FIG. 10 . The input for the flow at S 1302  is the integrated multicast routing table shown in  FIG. 15 . The flow of S 1303 -E 1  extracts a list of each of the items in  FIG. 15 . The flow at S 1305 -E 1  extract list of all pairs of multicast groups and sources, i.e. items # 1 , # 3 , # 4  and # 6  are listed, and items # 2  and # 5  are listed. The flow at S 1306 -E 1  initiates a loop for each of the two pairs, i.e. (2001:db8::10, ff38::1) and (2001:db8::10, ff38::2). The flow at S 1307 -E 1   a  provides two leaves for the pair (2001:db8::10, ff38::1), i.e. outgoing interface of items # 4  and # 6 , and one leaf for the pair (2001:db8::10, ff38::2), i.e. outgoing interface of item # 5 . The flow at S 1308 -E 1  initiates a loop for each of the leaves. 
         [0074]    When the leaf is the outgoing interface of item # 4 , the flow at S 1307 -E 1   b  set router  2  as current router. The flow at S 1309 -E 1  determines router  1  to be the upstream neighbor of item # 4 . The flow at S 1310 -E 1  sets router  1  as current router, and the item of this current router, i.e. the item of router  1  that has the same pair (2001:db8::10, ff38::1) as item # 4  is item # 1 . The flow at S 1309 -E 1  for the second iteration of the loop determines that there is no upstream router about item # 1 . Thus, the flow diagram generates a part of path 1 , i.e. items # 1  and # 3 , in  FIG. 16 . In the same way, other part of path 1 , i.e. items # 1 , # 2  and # 4 , and path 2 , i.e. items # 5  and # 6 , in  FIG. 16  are generated from items # 6 , # 3  and # 1 , and items # 5  and # 2  in  FIG. 15 . 
         [0075]      FIG. 17  illustrates an analyzed packet information table, in accordance with an example implementation. Time column indicates monitored time and duration indicates monitoring duration. Packets column indicates packet counts, but others measurements are also possible depending on the desired implementation e.g. octet counts, packet loss, delay, jitter, etc. Stream info as indicated in the note column indicates that the analyzed packet information contains stream information such as (2001:db8::10, ff38::1). 
         [0076]      FIG. 18  illustrates a data plane packet information table, in accordance with an example implementation. The data plane packet information table is generated at the flow for data plane information generation  131   a   1  in  FIG. 6  by selecting data plane packet information, e.g. MPEG stream, from  FIG. 17 . The selection of the data plane packet information occurs at the flow of S 1403  in  FIG. 9 . 
         [0077]      FIG. 19  illustrates the control plane packet information table generated at control plane information generating part  131   a   2  in  FIG. 6  by selecting control plane packet information, e.g. PIM Join and MLD Report, from  FIG. 17 . The selection corresponds to the flow of S 1403  in  FIG. 9 . 
         [0078]      FIG. 20  illustrates the data plane and path matching table generated at data plane and path matching part  132   a   1  in  FIG. 6  by extracting items from  FIG. 18  those that match path information in  FIG. 16 . For example, items # 1 , # 3  in  FIG. 18  match item # 1  in  FIG. 16  and items # 5 , # 7  in  FIG. 18  match item # 3  in  FIG. 16 , and those become items # 1  and # 3  in  FIG. 20 . The described flow is the execution of S 1405  in  FIG. 9 . 
         [0079]      FIG. 21  illustrates a control plane and path matching table, in accordance with an example implementation. The table is generated at control plane and path matching at the flow of  132   a   2  in  FIG. 6  by extracting items in  FIG. 19  those match path information in  FIG. 16 , e.g. item # 1  in  FIG. 19  matches item # 1  in  FIG. 16  and items # 3 , # 5  in  FIG. 19  match item # 3  in  FIG. 16 , and those become items # 1 , # 3  and # 4  in  FIG. 21 . This is executed at the flow of S 1405  in  FIG. 9 . 
         [0080]      FIG. 22  illustrates an example of anomaly criteria for data plane, in accordance with an example implementation. The anomaly criteria is stored at anomaly criteria  132   c  in  FIG. 6 . The anomaly criteria indicate that numbers of packets at an incoming interface and an outgoing interface of the same router on a path are the same. This example of anomaly criteria can be a comparison between any two points on the same path though the example of anomaly criteria in  FIG. 22  is a comparison between an incoming interface and an outgoing interface on the same router. 
         [0081]      FIG. 23  illustrates an example of anomaly criteria for control plane, in accordance with an example implementation. The anomaly criteria is stored at anomaly criteria  132   c  in  FIG. 6 . The anomaly criteria indicates that the PIM Join is robust to 2 packet losses in 3 cycles (e.g. 180 seconds) and the MLD Report is robust to 1 packet loss in 2 cycles (e.g. 250 seconds). 
         [0082]      FIG. 24  illustrates data plane anomaly monitoring table generated at data plane anomaly monitoring part  132   b   1  in  FIG. 6 . This table is subset of data plane and path matching table in  FIG. 20  at the time 01:00:01 because anomaly criteria for data plane in  FIG. 22  can be adapted to any duration. The described flow is the execution of S 1407  in  FIG. 9 . 
         [0083]      FIG. 25  illustrates control plane anomaly monitoring table generated at control anomaly monitoring part  132   b   2  in  FIG. 6 . This table is generated by gathering each item of control plane and path matching table in  FIG. 21 , i.e. gathering items during 00:03:00 for PIM Join because the anomaly criteria for control plane in  FIG. 23  requires duration of 3 cycles, and gathering items during 00:04:10 for MLD Report because anomaly criteria for control plane in  FIG. 23  requires a duration of 2 cycles. This flow is the flow of S 1407  in  FIG. 9 . 
         [0084]    Second Example Implementation of Complex Multicast Service 
         [0085]    In an example implementation for multicast service, there can be a re-transmission server that connects a plurality of multicast streams, such as a server for inserting advertisement, server for multiplexing multiple streams into one multicast stream, and so on. In such example implementations, the re-transmission server can operate as a sender as well as a receiver.  FIGS. 26 to 30  illustrate various aspects of the complex multicast service case, in accordance with an example implementation. 
         [0086]      FIG. 26  illustrates an example system diagram for the complex multicast service case, in accordance with an example implementation. In the present example implementation, a re-transmission server  230  that connects multiple multicast streams, e.g. server for inserting advertisement, server for multiplexing multiple streams into one multicast stream, and so on. 
         [0087]      FIG. 27  illustrates a flow diagram for a retransmission server in accordance with an example implementation. In this example implementation, the flow takes place from S 1313  of  FIG. 10 . The process begins at S 1313 -E 2 , when path relation information is obtained. At S 1314 -E 2 , the flow extracts the list of relations between paths based on the obtained path relation information. At S 1315 -E 2 , the flow initiates a loop for each relation from the path relation information. At S 1316 -E 2  the flow connects related paths. At S 1317 -E 2 , the flow ends the loop for the relation. When all relations are processed, the process terminates at S 1318 -E 2 . 
         [0088]      FIG. 28  illustrates a sequence diagram for the complex multicast service case, in accordance with an example implementation. In the example implementation of  FIG. 28 , there is a re-transmission server  230 , a service request such as MLD Report and PIM Join are changed at the re-transmission server  230 , and multicast streams are connected at the re-transmission server  230 . As shown in  FIG. 26 , the re-transmission server  230  is a sender as well as a receiver. 
         [0089]      FIG. 29  illustrates a service request diagram for the complex multicast service case, in accordance with an example implementation. S 2102   a   1  illustrates a MLD Report for a multicast stream  1 , and S 2103   a   1  illustrates a PIM Join for a multicast stream  1  as illustrated in  FIG. 28 . S 2102   a   2  and S 2102   b   2  illustrates a MLD Report for a multicast stream  2  in  FIG. 26( c ) , and (S 2103   a   2 ) and (S 2103   b   2 ) show PIM Join for multicast stream  2  in  FIG. 26 . S 2102   a   1  and S 2103   a   1  contain the same multicast group and source that indicates a multicast stream  1 , and S 2102   a   2 , S 2102   b   2 , S 2103   a   2  and S 2103   b   2  contain the other same multicast group and source that indicates a multicast stream  2 . 
         [0090]      FIG. 30  illustrates a service stream diagram for the complex multicast service case, in accordance with an example implementation. S 2104   a   1 , S 2104   b   1  and S 2104   c   1  illustrate the multicast stream  1  as shown in  FIG. 27 . The multicast group and source is the same as that of MLD Report S 2102   a   1  and PIM Join S 2103   a   1  for multicast stream  1  in  FIG. 29 , and S 2104   a   2 , S 2104   b   2 , S 2104   c   2 , S 2104   d   2  and S 2104   e   2  show multicast stream  2  shown in  FIG. 28  and the multicast group and source is the same as that of MLD Report S 2102   a   2 , S 2102   b   2  and PIM Join S 2103   a   2 , S 2103   b   2  in  FIG. 29 . 
         [0091]      FIG. 31  illustrates an integrated multicast routing table that can be generated at route analyzing module ( 102 ) by gathering routing tables from each router, i.e. item # 1  is from Router  1  ( 200   a ), items # 2 , # 3  and # 4  are from Router  2  ( 200   b ), item # 5  is from Router  3  ( 200   c ), and item # 6  is from Router  4  ( 200   d ). Service stream  1  is the stream with the pair (2001:db8::10, ff38::1) and service stream  2  is the stream with the pair (2001:db8::12, ff38::2). In reference to  FIG. 26( e ) , item # 1  shows route for service stream  1  S 2104   b   1 , # 2  shows route for service stream  1  S 2104   c   1 , # 3  shows route for service stream  2  S 2104   b   2 , # 4  shows route for service stream  2  S 2104   d   2 , # 5  shows route for service stream S 2104   e   2 , and # 6  shows route for service stream  2  S 2104   c   2 . Router  2  ( 200   b ) has flags LH for service stream  1  and FH for service stream  2 . 
         [0092]      FIG. 32  illustrates path information table without connection that is generated at path information block ( 120 ) by the flow diagram of  FIG. 10  by using  FIG. 31  as input. The flow at S 1303 -E 1  extracts the list of each of the items in  FIG. 31 . The flow at S 1305 -E 1  extract list of all pairs of multicast group and source, i.e. items # 1 , # 2  are listed, items # 3 , # 5  are listed, and items # 3 , # 6  are listed. The flow at S 1306 -E 1  makes a loop for two pairs, i.e. (2001:db8::10, ff38::1) and (2001:db8::12, ff38::2). The flow at S 1307 -E 1   a  provides one leaf for the pair (2001:db8::10, ff38::1), i.e. outgoing interface of item # 2 , and two leaves for the pair (2001:db8::12, ff38::2), i.e. outgoing interface of items # 5  and # 6 . The flow at S 1308 -E 1  makes loop for above each leaf. When the leaf is outgoing interface of item # 2 , the flow at S 1307 -E 1   b  set router  2  as current router. The flow at S 1309 -E 1  find router  1  to be the upstream neighbor of item # 2 . The flow at S 1310 -E 1  sets router  1  as current router, and the item of this current router, i.e. the item of router  1  that has the same pair (2001:db8::10, ff38::1) as item # 2  is item # 1 . The flow at S 1309 -E 1  for the second time find there is no upstream router about item # 1 . These series of steps generates the path 1 , i.e. items # 1  and # 2 , in  FIG. 32 . In the same way, path 2  in  FIG. 32  is generated from items # 3  and # 5 , and items # 4  and # 6  in  FIG. 31 . 
         [0093]      FIG. 33  illustrates a path connection table, in accordance with an example implementation. The path connection table is gathered from the re-transmission server e.g. its configuration or generated from comparison between contents of incoming and outgoing streams by route analyzing module  102 . The pair (2001:db8::10, ff38::1) indicates multicast stream  1  arrived at the re-transmission server and the pair (2001:db8::12, ff38::2) indicates multicast stream  2  departed from the re-transmission server. This information is an input for the flow at S 1313 -E 2  and listed at the flow of S 1314 -E 2  in the flow diagram of  FIG. 27 . The flow of S 1315 -E 2  initiates a loop for the relation based on  FIG. 33 . In this example, there is one item # 1 . The flow of S 1316 -E 2  connects path 1  and path 2  based on this item # 1  by comparing each pair of group and source between  FIG. 32  and  FIG. 33 . As a result of these steps, the path information table of  FIG. 34  can be generated. 
         [0094]      FIG. 35  illustrates an analyzed packet information table, in accordance with an example implementation. In the example of  FIG. 35 , the time indicates monitored time and duration indicates the monitoring duration. “Packets” indicates packet counts. Others fields are possible as measurements in accordance with the desired implementation, such as octet counts, packet loss, delay, jitter, and so on. Stream info at note indicates that the analyzed packet information contains stream information such as stream 1  (2001:db8::10, ff38::1) and stream 2  (2001:db8::12, ff38::2). 
         [0095]      FIG. 36  illustrates the data plane packet information table generated at the data plane information generating part for data plane information generation  131   a   1  in  FIG. 6  by selecting data plane packet information, e.g. MPEG stream, from  FIG. 34 . The selection of the data plane packet information occurs at the flow of S 1403  in  FIG. 9 . The information table of  FIG. 36  can be implemented similarly to  FIG. 18 . Similar tables for generating and utilizing a data plane and path matching table, and control plane and path matching table can be implemented as illustrated in  FIGS. 18-21  by utilizing the flow diagram of  FIG. 9  for the retransmission server case, and can be utilized for facilitating the desired multicast implementation. 
         [0096]    Third Example Implementation of Unicast Service 
         [0097]    In a third example implementation, for unicast service case, there can be a session management server that mediates between a sender and a receiver if the service is client-server model or between users if the service is peer-to-peer model. 
         [0098]      FIG. 37  illustrates an example system diagram for the unicast service case, in accordance with an example implementation. In the example of  FIG. 37 , there is a session management server ( 240 ) that mediates between sender and receiver if the service is client-server model or between users if the service is peer-to-peer model. 
         [0099]      FIG. 38  illustrates a sequence diagram in the case of client-server model such as video on demand service in accordance with an example implementation. When receiver  220  starts receiving a video stream, receiver  220  sends a session request (as shown at S 2105   a ) with information that indicates requesting contents to session management server  240 , and. Session management server  220  sends service request with information that indicates the requesting receiver to sender  210  as shown at S 2106   a . After the request reaches sender  210 , the requested service stream is transmitted from sender  210  to receiver  220  as shown at S 2107  in unicast, and as shown at  2106   b  and  2105   b  as a session reply. Session request S 2105   a , and reply S 2105   b , and service request S 2106   a  and reply S 2106   b  are illustrated. The endpoint information, i.e. IP of sender  210  and receiver  220 , and operation can be extracted from these request and reply messages. Unicast service stream S 2107  is transmitted from sender  210  to receiver  220 . 
         [0100]      FIG. 39  illustrates a service request diagram, in accordance with an example implementation. S 2105  illustrates session request and reply, and S 2106  illustrates a service request and reply. The information of endpoints, i.e. IP of sender  210  and receiver  220 , and operation can be extracted from these request and reply messages.  FIG. 40  illustrates a service stream diagram, in accordance with an example implementation. S 2107  shows service stream transmitted from sender  210  to receiver  220 . 
         [0101]      FIG. 41  illustrates the packet format that is used for session/service construction in  FIGS. 37 to 40 . Several protocols such as HTTP (HyperText Transfer Protocol), SIP, and so on, are used as payload, and IP header and/or payload contain the information of endpoints of the service and operation such as starting or stopping the service. 
         [0102]      FIG. 42  shows an integrated unicast routing table representative of the network topology that is generated at the route analyzing module  102  by gathering routing tables from each router, i.e. items # 1 -# 7  are from Router 1   200   a  as illustrated in  FIGS. 39 and 40 , items # 8 -# 14  are from Router 2   200   b , items # 15 -# 21  are from Router 3   200   c , and items # 22 -# 28  are from Router 4   200   d . The flag C indicates the outgoing interface is neighboring the destination of that item. Normally unicast routing table includes all available routing information regardless of traffic existence. 
         [0103]      FIG. 43  shows analyzed packet information table, in accordance with an example implementation. Time means monitored time and duration means duration of monitoring. Packets means packet counts but others are possible as measurements e.g. octet counts, packet loss, delay, jitter, etc. Stream info at note means this analyzed packet information contains stream information such as Sender IP (2001:db8::10), Receiver IP (2001:db8::11), operation commands (start, stop, etc.) though not clearly shown in this table. 
         [0104]      FIG. 44  illustrates target path information table generated at target path block  110 , in accordance with an example implementation, for a unicast service when utilizing the flow of  FIG. 7( a ) . The input of the flow at S 1102  is analyzed packet information table shown in  FIG. 43 . At S 1103 , the flow extracts service request packets which includes endpoints of service, i.e. extracts packets including stream info at note e.g. item # 3 , # 6 , etc. in  FIG. 43  and gets each source IP and destination IP, including that of the session management server and stream information indicated by the stream info at note (e.g. Sender IP (2001:db8::10), Receiver IP (2001:db8::11), operation commands (start, stop, etc.)) as contained in those packets. The flow at S 1104  makes the loop for each extracted packets. The flow at S 1105  judges above operation commands. The flow at S 1106  adds new endpoints to the target path information table if the flow at S 1105  indicates the start operation, and the flow at S 1107  deletes old endpoints from target path information table if the flow S 1105  indicates the stop operation. If a service creates a specific route when the service stars and deletes when the service stops, the target path information table is generated with routing table as illustrated in  FIG. 42  by following the flow of  FIG. 7( a ) . 
         [0105]      FIG. 45  shows path information table that is generated at path information block  120  through the use of the flow diagram  FIG. 8  for a unicast service. The input for the flow at S 1302  is integrated unicast routing table shown in  FIG. 42 . The flow at S 1303  extracts list of each item in  FIG. 42 . The input of flow at S 1304  is target path information table shown in  FIG. 44 . The flow at S 1305  extracts list of each item of  FIG. 44 . The flow at S 1306  makes loop for each endpoint, i.e. source 2001:db8::10, destination 2001:db8::11 and related server 2001:db8::12. The flow at S 1307  provides routers neighboring above each endpoint, i.e. router 1 , router 3  and router 2  for each based on items # 4 , # 26  and # 13  in  FIG. 41 . The flow at S 1308  makes loop for each pair of endpoints, i.e. (2001:db8::10, 2001:db8::11) related to data plane i.e. stream data transmission, and (2001:db8::11, 2001:db8::12) and (2001:db8::12, 2001:db8::10) related to control plane i.e. service session management. When the pair of endpoints is (2001:db8::10, 2001:db8::11), initial current router neighboring the endpoint 2001:db8::10 is router 1  and step S 1309  looks for route toward the other endpoint 2001:db8::11 and finds item # 5  in  FIG. 42 . The flow at S 1310  set router 2  as next current router. The flow at S 1309  for the second time finds item # 12  in  FIG. 42  and the flow at S 1310  set router 4  as next current router. The flow at S 1309  for the third time finds item # 26  that indicates the other endpoint 2001:db8::11 is neighboring router 4  and there is no next router. The flow generates a part of path 1 , i.e. items # 1 , # 2  and # 3 , in  FIG. 45 . In the same way, other parts of path 1 , i.e. items # 4  and # 5 , and items # 6  and # 7  in  FIG. 45  are generated from items # 27  and # 13 , and items # 11  and # 4  in  FIG. 42 . Similar tables for generating and utilizing a data plane and path matching table, control plane and path matching table, data plane and path matching table, and control plane and path matching table as illustrated in  FIGS. 18-21 , can be implemented in accordance with the flow diagram of  FIG. 9  for facilitating the desired unicast implementation. 
         [0106]    Fourth Example Implementation for Mobile Service Case 
         [0107]      FIG. 46  illustrates a system environment for the mobile service case, in accordance with an example implementation. The difference from  FIG. 5  is there are several mobile equipment i.e. S/P GW (Serving/PDN Gateway)  251 , MME (Mobility Management Entity)  252  and eNB (evolved Node B) ( 253 ) for managing the mobile session. 
         [0108]      FIG. 47  illustrates a sequence diagram, in accordance with an example implementation. When UE (User Equipment)  260  starts receiving service stream, it sends connection request via eNB  253  to MME  252  (S 2108 ). MME  252  sends session request to S/P GW  251  (S 2109 ). After these requests finished, UE  260  sends service request to sender  210  (S 2110 ), and requested service stream is transmitted from sender  210  to UE  260  (S 2111 ). 
         [0109]      FIG. 48  and  FIG. 49  illustrate packet formats those are used for connection/session/service construction in  FIG. 47 , in accordance with an example implementation. IP header and/or payload contain the information of endpoints of the service and operation such as starting or stopping the service. 
         [0110]      FIG. 50  illustrates a service request diagram for mobile service, in accordance with an example implementation. (S 2108 ) shows connection request and reply shown in  FIG. 47 , (S 2109 ) shows session request and reply shown, and (S 2110 ) shows service request shown in  FIG. 47 . As mentioned about  FIG. 48  and  FIG. 49 , the information of endpoints, i.e. IP of sender  210  and UE 1   260   a , and operation can be extracted from these request and reply messages. 
         [0111]      FIG. 51  illustrates an example service stream diagram, in accordance with an example implementation. S 2111  illustrates service stream transmitted from sender  210  to UE 1   260   a  as shown in  FIG. 47 . 
         [0112]      FIG. 52  illustrates an integrated unicast routing table about the network topology, in accordance with an example implementation. The network topology of  FIG. 52  is generated at route analyzing module ( 102 ) in  FIG. 46  by gathering routing tables from each equipment, i.e. items # 1 -# 3  are from Router 2  ( 200 ), items # 4 -# 10  are from S/P GW ( 251 ), items # 11 -# 13  are from MME ( 252 ), and items # 14 -# 20  are from eNB ( 253 ). The flag C indicates that the outgoing interface is neighboring the destination of the item. The flag T indicates outgoing interface is tunneled interface between S/P GW and eNB via Router 2  with a packet format shown in  FIG. 49 . 
         [0113]      FIG. 53  illustrates an analyzed packet information table, in accordance with an example implementation. Time indicates the monitored time and duration indicates the duration of monitoring. Packets indicates the packet count, however other measurements may also be applied according to the desired implementation, such as octet counts, packet loss, delay, jitter, and so on. Stream info at note indicates that the analyzed packet information contains stream information such as Sender IP (2001:db8::10), UE IP (2001:db8::11), operation commands (start, stop, etc.) though not clearly shown in this table. The IP 2001:db8::1* means IP 2001:db8::10 is encapsulated by 2001:db8::1, and IP 2001:db8::4* means IP 2001:db8::11 is encapsulated by 2001:db8::4 because of tunneled interface between S/P GW and eNB via Router 2  with a packet format shown in  FIG. 49 . 
         [0114]      FIG. 54  illustrates a target path information table generated at target path block ( 110 ) in  FIG. 46  by applying the flow diagram  FIG. 7 , in accordance with an example implementation. Through applying the flow diagram of  FIG. 7 , the input of the flow at S 1102  in  FIG. 7  is analyzed packet information table shown in  FIG. 43 . The flow at S 1103  extracts the service request packets those include endpoints of service, i.e. extracts packets including stream info at note e.g. item # 2 , # 6 , etc. in  FIG. 53  and gets each source IP and destination IP including that of S/P GW, MME, eNB and stream information shown at note such as Sender IP (2001:db8::10), Receiver IP (2001:db8::11), operation commands (start, stop, etc.) contained in those packets. The flow at S 1104  makes a loop for each of the extracted packets. The flow at S 1105  judges above operation commands. The flow at S 1106  adds new endpoints to target path information table if the result of the flow at S 1105  indicates starting, and the flow at S 1107  deletes old endpoints from target path information table if the result of the flow at S 1105  indicates stopping. If a service creates specific route when the service stars and deletes when the service stops, target path information table is generated with routing table such as  FIG. 52  by executing a flow diagram based on  FIG. 7  and as according to the desired implementation. 
         [0115]      FIG. 55  illustrates a path information table for mobile service that is generated at path information block ( 120 ) in  FIG. 46  by the steps of flow diagram  FIG. 8 . The input for the flow at S 1302  is integrated unicast routing table shown in  FIG. 52 . The flow at S 1303  extracts list of each item in  FIG. 52 . The input of the flow at S 1304  is target path information table shown in  FIG. 54 . The flow at S 1305  extracts the list of each item. The flow at S 1306  makes a loop for each endpoint, i.e. source 2001:db8::10, destination 2001:db8::11 and related equipment 2001:db8::1, 2001:db8::3, 2001:db8::4. The flow at S 1307  provides equipment neighboring above each endpoint, i.e. S/P GW, eNB and router 2  for each based on items # 7 , # 18  and # 1 -# 3  in  FIG. 52 . The flow at S 1308  makes loop for each pair of endpoints, i.e. (2001:db8::10, 2001:db8::11) related to data plane i.e. stream data transmission, and (2001:db8::3, 2001:db8::1), (2001:db8::4, 2001:db8::3) and (2001:db8::11, 2001:db8::10) related to control plane i.e. connection/session/service management. When the pair of endpoints is (2001:db8::10, 2001:db8::11), the initial current equipment neighboring the endpoint 2001:db8::10 is S/P GW and the flow at S 1309  looks for the route toward the other endpoint 2001:db8::11 and finds item # 8  in  FIG. 52 . The flow at S 1310  set router 2  as next current equipment though IP of the other endpoint is 2001:db8::4 because item # 8  in  FIG. 52  indicates tunneled interface. The flow at S 1309  for the second time finds item # 3  in  FIG. 52  and the flow at S 1310  set eNB as next current equipment. The flow at S 1309  for the third time finds item # 18  that indicates the other endpoint 2001:db8::11 is neighboring eNB and there is no next equipment. This flow diagram generates a part of path 1 , i.e. items # 1 , # 2  and # 3 , in  FIG. 55 . In the same way, other parts of ptah 1  in  FIG. 55  are generated. 
         [0116]      FIG. 56  illustrates a data plane packet information table generated at data plane information generating part  131   a   1  in  FIG. 6  by selecting data plane packet information, e.g. MPEG stream, from  FIG. 53 . This table corresponds to the flow at S 1403  in  FIG. 9 . Similar tables for generating and utilizing a data plane and path matching table, control plane and path matching table, data plane and path matching table, and control plane and path matching table can be implemented as in  FIGS. 18-21  can be utilized for facilitating the desired mobile service implementation. 
         [0117]      FIG. 57  illustrates an example computing environment with an example computer device suitable for use in some example implementations, such as an apparatus to facilitate the functionality of navigating another movable apparatus. Computer device  5705  in computing environment  5700  can include one or more processing units, cores, or processors  5710 , memory  5715  (e.g., RAM, ROM, and/or the like), internal storage  5720  (e.g., magnetic, optical, solid state storage, and/or organic), and/or I/O interface  5725 , any of which can be coupled on a communication mechanism or bus  5730  for communicating information or embedded in the computer device  5705 . 
         [0118]    Computer device  5705  can be communicatively coupled to input/user interface  5735  and output device/interface  5740 . Either one or both of input/user interface  5735  and output device/interface  5740  can be a wired or wireless interface and can be detachable. Input/user interface  5735  may include any device, component, sensor, or interface, physical or virtual, that can be used to provide input (e.g., buttons, touch-screen interface, keyboard, a pointing/cursor control, microphone, camera, braille, motion sensor, optical reader, and/or the like). Output device/interface  5740  may include a display, television, monitor, printer, speaker, braille, or the like. In some example implementations, input/user interface  5735  and output device/interface  5740  can be embedded with or physically coupled to the computer device  5705 . In other example implementations, other computer devices may function as or provide the functions of input/user interface  5735  and output device/interface  5740  for a computer device  5705 . 
         [0119]    Examples of computer device  5705  may include, but are not limited to, highly mobile devices (e.g., smartphones, devices in vehicles and other machines, devices carried by humans and animals, and the like), mobile devices (e.g., tablets, notebooks, laptops, personal computers, portable televisions, radios, and the like), and devices not designed for mobility (e.g., desktop computers, other computers, information kiosks, televisions with one or more processors embedded therein and/or coupled thereto, radios, and the like). 
         [0120]    Computer device  5705  can be communicatively coupled (e.g., via I/O interface  5725 ) to external storage  5745  and network  5750  for communicating with any number of networked components, devices, and systems, including one or more computer devices of the same or different configuration. Computer device  5705  or any connected computer device can be functioning as, providing services of, or referred to as a server, client, thin server, general machine, special-purpose machine, or another label. 
         [0121]    I/O interface  5725  can include, but is not limited to, wired and/or wireless interfaces using any communication or I/O protocols or standards (e.g., Ethernet, 802.11x, Universal System Bus, WiMAX, modem, a cellular network protocol, and the like) for communicating information to and/or from at least all the connected components, devices, and network in computing environment  5700 . Network  5750  can be any network or combination of networks (e.g., the Internet, local area network, wide area network, a telephonic network, a cellular network, satellite network, and the like). 
         [0122]    Computer device  5705  can use and/or communicate using computer-usable or computer-readable media, including transitory media and non-transitory media. Transitory media include transmission media (e.g., metal cables, fiber optics), signals, carrier waves, and the like. Non-transitory media include magnetic media (e.g., disks and tapes), optical media (e.g., CD ROM, digital video disks, Blu-ray disks), solid state media (e.g., RAM, ROM, flash memory, solid-state storage), and other non-volatile storage or memory. 
         [0123]    Computer device  5705  can be used to implement techniques, methods, applications, processes, or computer-executable instructions in some example computing environments. Computer-executable instructions can be retrieved from transitory media, and stored on and retrieved from non-transitory media. The executable instructions can originate from one or more of any programming, scripting, and machine languages (e.g., C, C++, C#, Java, Visual Basic, Python, Perl, JavaScript, and others). 
         [0124]    Computer device  5705  can be configured to implement the architecture as illustrated for example, in  FIGS. 2, 5, 6 and 46 , and can be facilitated to execute the flow diagrams as illustrated in  FIGS. 7-10 . Memory  5715  can be configured to store management information as illustrated in the tables (e.g.,  FIGS. 15-29 ), to facilitate the execution of the flow diagrams. 
         [0125]    In example implementations, computer device  5705  can be in the form of a management computer configured to manage a network as illustrated, for example, in  FIGS. 2, 5, 6 and 46 . In such an example implementation, memory  5715  can be configured to store anomaly criteria information for the network and path information for the network as illustrated in  FIGS. 20-23 . Processor(s)  5710  may be configured to apply the path information to at least one of data plane packet information and control plane packet information to generate matching information, the matching information involving first entries from at least one of the data plane packet information and control plane packet information having sources matched to corresponding second entries from the path information having paths corresponding to the sources as described with respect to  FIGS. 17-24  with respect to the flow diagrams of  FIGS. 6 to 10  and monitor the network for an anomaly based on the matching information and the anomaly criteria information. 
         [0126]    The path information can include incoming interface information and outgoing interface information for each router in each of the paths, wherein the control plane packet information can include incoming control plane packet information and outgoing control plane packet information for each interface of each router. Processor(s)  5710  can be configured to generate the matching information by matching first information from the path information, the first information involving the incoming interface information and the outgoing interface information for each of the paths, to second information from the control plane packet information, the second information comprising the incoming control plane packet information and the outgoing control plane packet information associated with an interface that matches an interface indicated by the incoming interface information and the outgoing interface information. Similarly, processor(s)  5710  can be configured to match first information from the path information, the first information including the incoming interface information and the outgoing interface information for each of the paths, to second information from the data plane packet information, the second information including the incoming data plane packet information and the outgoing data plane packet information associated with an interface that matches an interface indicated by the incoming interface information and the outgoing interface information. 
         [0127]    Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result. 
         [0128]    Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system&#39;s registers and memories into other data similarly represented as physical quantities within the computer system&#39;s memories or registers or other information storage, transmission or display devices. 
         [0129]    Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation. 
         [0130]    Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers. 
         [0131]    As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format. 
         [0132]    Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.