JP4706979B2 - Method and system for communicating predicted network behavior between interconnected networks - Google Patents

Description

[Priority claim]
This application is filed under 35 USC §119 (e) for priority to US provisional application 60,647,900 “METHOD AND SYSTEM FOR COMMUNICATING MODELS OF NETWORK BEHAVIOR BETWEEN NETWORKS” filed on January 28, 2005. . The entire contents of this application are incorporated herein by this reference.

[Technical field]
This group of embodiments relates to the general technical field of network data communication, and in one example embodiment, a method and system for communicating predicted network behavior between interconnected networks. Related.

  In a network, such as a telecommunications network, data or traffic is delivered from an information source to a destination in a communication line. This network may be operated by a company that uses the network for its own private communication. Such a network may also be operated by a service provider, which allows others to use it to communicate their data.

  If two or more network operators allow the transmission of traffic between their respective networks, the communication range available to people using those networks may be expanded and useful. The Internet is the largest collection of such intercommunication networks. Network operator A can also pay another network operator B to obtain permission for traffic originating from or sending to network A users to travel over network B. In other words, this configuration means that the network A purchases the right to pass through the network B. In addition, as a mutual configuration between networks A and B, it is possible to obtain permission to transmit traffic on the other network for each network user as a transmission source and transmission destination without requiring payment. May be set. Such a configuration is known as peering. A certain network may conclude a plurality of passing / peering configurations with another network group.

  In this document, specific mechanisms are described to facilitate the implementation of peering and passing configurations. In the specific example of two networks, A and B, traffic is considered to be exchanged. For convenience, A and B are considered peered to each other even though the contracted configuration may differ from the above peering definition. Although only two networks are referred to, these two networks may be contracted with other networks at the same time for traffic exchange. Also, the described mechanism may be extended to facilitate peering between multiple networks.

If network B wants to peer with another network A, the following two conditions are considered desirable.

1. Each network should know as much information as possible about another network to help predict and prepare for the nature of the traffic that can be exchanged between networks.

2. However, each network may limit as much as possible the knowledge that other networks have about their network. This is done, for example (among other reasons), if these networks belong to competing commercial entities to prevent other networks from gaining commercial advantage from knowledge.

  The type of information that the network B wants to know about the network A is the amount of traffic that flows through the network B with the network A as the start point or the end point; acceptance in the network B when the traffic enters and exits the network A These include, but are not limited to, entry points and exit points; and what route traffic will take within Network B. Network B also wants information about the changes that these characteristics of traffic may cause in the future due to: That is, a component failure in network A; a planned power outage in network A; and a routing policy or topology change in network A. In this specification, all these events are described as changes or failures in the network A. This is because causes other than actual network element failures can be attributed to events resulting from traffic transitions.

  This information is also useful for network B, and, among other reasons, plans the path of traffic entering and exiting network A and the path that other traffic will take within that network. Minimizing network overload or congestion, assisting with future changes in network design (including capacity and topology changes), and knowing what level of service can be offered to their customers now and in the future It can be said that it is useful because it can.

  In this specification, in order to balance the above-described conditions 1 and 2, a mechanism considering two peering networks A and B is proposed as an embodiment. This mechanism includes specific data structures that can be exchanged between the two networks. The data structure provided from network A to network B sufficiently elucidates, for example, current traffic behavior between two networks and possible future traffic behavior, so that network B can plan for the future. It will be useful in. At the same time, the structure provides only minimal information about the internal design of the network A itself, so the secret of the network A is preserved. Instead, network B provides a similar data structure to network A. Of course, network B can also compensate network A that provided this information in other ways, such as paying for the information.

  The method described here uses first and second networks. In certain cases, this information is provided from network A, the first network, to network B, the second network, and network B moves from network A to network B and accepts it to network B. Helps predict traffic behavior where the point is controlled by network A. Such a case is, for example, when the network A and the network B have a peering configuration. By extending this method, the network A provides the network B with information for predicting the operation of traffic from the network B to the network A, and the reception point to the network A is controlled by the network A. It can be easily adapted to the case. In this case, for example, the network A is a customer of the network B, and the network A pays the network B in order to obtain the function of specifying the reception point of the traffic from the network B to the network A. It sometimes happens.

  The modeling of networks A and B uses the concept of network traffic transmission request. These requests specify the amount of traffic from a particular source on the network (or traffic entering the network towards that source) and send the request to a specific destination within that network or another network. It is done. Thereafter, the path taken by the traffic for that request within the network is determined using a network routing protocol implemented by the respective network. The route setting protocol used on the Internet is IP (Internet Protocol). When different fault conditions occur in the network, it is considered that different paths are taken. To the extent permitted by IP, the network maintains some control of traffic routing. That is, in the above embodiment, the network A can control the reception point of the request from the network A to the network B.

  A method for estimating network requirements and a method for using information of network simulation for planning and changing a route set in the network in the future is described in U.S. Patent Application No. 10 / 937,988 “METHOD AND SYSTEM TO PERFORM TRAFFIC ENGINEERING IN A METRIC-ROUTED NETWORK”, the contents of which are incorporated herein by this reference.

  FIG. 1 is a block diagram showing the entire route setting exchange system. In this embodiment, it is composed of two subsystems 100 and 150. Subsystem 100 is under the control of network A operator. Subsystem 150 is under the control of Network B operator.

In the subsystem 100, three sets of data structures described below representing the network A and the connection of the network A to the network B are generated and used.

1. The topology structure 102 describes the topology of the network A in this embodiment. The topology structure 102 includes a representation of a link connecting the network A and the network B.

2. The request structure 103 describes a traffic request group between two points related to a transmission source in the network A and a transmission destination in the network B in this embodiment. These requests represent the amount of network traffic that Network A attempts to transmit to Network B from various points within Network A.

3. The fault structure 101 describes a list of scenarios in which elements in the network A change in this embodiment. The change referred to here may be a failure scenario or a maintenance scenario. Network A is desired to supply network B with information about the behavior of traffic entering network B from network A under the list of scenarios.

  Details of these structures are shown in FIGS.

  In some example embodiments, these structures are generated by modules (not shown) that form part of subsystem 100, ie, a network topology module, a traffic request module, and a traffic routing module.

  Using the data structures 101, 102, and 103, the peer link usage calculator 110 calculates the peer link usage structure 120. This calculator is further described in FIG. 11 and the resulting structure is described in FIG. The peer link usage structure describes how much traffic there is for each peering link from network A to network B under each failure scenario in failure structure 101.

  Using the peer link usage structure 120, the failover matrix composer 130 calculates the data changes that make up the failover matrix structure 140. This failover matrix structure 140 is transmitted from the subsystem 100 to the subsystem 150. The failover matrix structure 140 describes how traffic moves from one peering link to another peering link under the failover scenarios listed in the failure structure 101. Details of the failover matrix structure are shown in FIG. 7, and details of the failover matrix constructor are shown in FIG.

Subsystem 150 describes network B using the following three sets of data structures in the same form as 101, 102, 103.

1. The fault structure 151 describes a list of scenarios in which elements of network B fail in this example embodiment. Further, the failure structure 151 may include a scenario that the network B wants to include in the operation simulation of the network B, a scenario that the network B wants to include when planning future changes or optimization of the network B, and the like.

2. Topology structure 152 describes the topology of network B in this example embodiment. This structure includes a representation of the link from network B to network A.

3. The request structure 153 includes traffic requests (eg, all traffic requests) that, in this example embodiment, take a path through the network B, thus affecting the traffic usage and management of the network B. Request structure 153 specifically includes requests for a source in network A and a destination in network B, a request for a source and destination in network B, and a source in network B and a transmission in network A Including requests for destinations.

  As an example embodiment, these structures are generated by modules (not shown) that are part of subsystem 150, ie, a network topology module, a traffic request module, and a change module.

  In order to perform an operation simulation of the network B, the network simulator 160 uses information included in 151, 152, and 153 together with the failover matrix structure 140 received from the subsystem 100 by a receiving module (not shown). Specifically, the network simulator 160 creates a request route setting structure 165 that describes the route setting through the network B for each request 153 under each failure scenario described in 151. If any of these failure scenarios involves the failure of one or more peering links from network A to network B, the network simulator 160 refers to the failover matrix structure 140 via the peering link. Defines the behavior of requests entering network B through network A. Details of the network simulator 160 are shown in FIG.

  The request routing structure 165 may be displayed on the GUI 170 by the network B controller in order to visualize the operation of the network under a failure scenario. Details of the elements of the GUI are shown in FIG. The request path setting structure 165 can also be used as an input to the network design tool 180. The network design tool 180 can suggest modification or optimization of the network design or routing policy to reduce the impact of the described possible failures.

  FIG. 2 shows an implementation model of the network A used by an operator of the network A, and the data structure used in the system of FIG. 1 will be described based on this. In this embodiment, the network A 200 is composed of a set of six nodes or routers N1 (201) to N6. These nodes are connected by a two-way link. For example, 202 connects N1 and N4. Network B is shown as a single node 210 because the operator of network A does not know the topology of network B. Peering links (P1, P2 and P3, 220-222) connecting between network A and network B are connected from network A node to network B.

  Three route requests are displayed in FIG. DA1, DA2 and DA3 (230-232) are traffic requests from N1, N2 and N3 to NB, respectively. An example of routing these requests is through the network A link and through the peering link, as shown. These are routed under normal operation (for example, when there is no faulty element in network A). Requests DA1, DA2 and DA3 are carried in traffic of 50, 100 and 100 Mb / s (megabits per second), respectively. Note that DA3 has a branched route. This can be achieved, for example, by using an IGP shortest-path first routing protocol. Half of the traffic for this request takes one path to the destination and the other half takes another path.

  FIG. 3 is an implementation model of the network B used by the operator of the network B. Based on this, the data structure used in the system of FIG. 1 will be described below. In this embodiment, the network B 300 is composed of a set of six nodes or routers N7 (301) to N12. These nodes are connected by a two-way link. Network A is shown as a single node 310 because the operator of network B does not know the topology of network A. The peering links (P1, P2, P3, 320-322) between network A and network B are links 220-222 in FIG.

  Three route requests are represented in FIG. DB1, DB2, and DB3 (330-332) are traffic requests from NA to N10, N11, and N11, respectively. An example of routing these requests is through the peering link and through the network B link, as shown. Under normal operation, the same route setting as the request route setting in FIG. 2 is performed.

  FIG. 4 illustrates two data structures used by both subsystem 100 and subsystem 150 of FIG. 1 to store data used in creating and using the failover matrix structure 140. In FIG. 4, for the purpose of explanation, these structures are filled with data representing the embodiment of the network A of FIG.

The topology structure 400 includes a table where, in one embodiment, each row represents a link in the topology. The columns in this table can be as follows:

1. Link ID: Character string for link identification

2. From: A node that joins the link and sends data on the link

3. From Node / AS: Node if the From node is a physical node, or AS (Autonomous System) if the From node represents other networks collectively

4). To: Node that joins the link and receives data from the link

5. To Node / AS: Same as From Node / AS, but described for To node

Request structure 410 includes a table that lists the requests in the topology in each row. The columns of the table can be as follows:

1. Request ID: Character string for request identification

2. Source—Source node or source AS that begins to pass traffic through the network

3. Destination—Destination node or destination AS that receives the transmission of traffic through the network

4). Traffic (Mb / s): The amount of traffic sent in Mb / s (megabits per second) or other units

  FIG. 5 illustrates a failure structure 500 that, in the example embodiment, is used by both subsystems 100 and 150 of FIG. 1 to describe failure scenarios associated with the creation and use of failover matrix structure 140. .

  The failure structure 500 includes, as an illustrative example, descriptions of three failure scenarios in the embodiment of the network A in FIG. Fault structure 500 may be a table where each row indicates a specific fault scenario. Each column in this table represents a link in the network. Each entry field in this table is left blank or X is entered. An X in a particular row / column indicates that the failure scenario indicated by that row includes (at least) the failure of the link indicated by that column. Three failure scenarios of 500 represent failure of the three peering links 220-222 of FIG.

  Note that a single failure scenario can include multiple link failures. For example, failure structure 510 includes a description that network B of FIG. 3 fails. The displayed failure is a failure of a node in the network and is described as a failure of all links connected to the node. Therefore, in this table, links P2, N8-N7, and N8-N10 (extracted from other links) are marked with an X.

  FIG. 6 represents an embodiment of the network A of FIG. 2 in a specific failure state. An example of creating the peer link usage structure and failover matrix structure of FIG. 7 will be described using this figure.

  Network A 600 is the same network as that of FIG. In this figure, x mark 610 indicates that one of the peering links P2 has failed. This is the failure scenario shown in the second row of the table of structure 500 of FIG. The three requests DA1, DA2, and DA3 (601-603) are re-routed to avoid peering link failures. In this failure scenario, these requests use only the peering links P1 and P3 until they reach the NB in the network B which is a common destination.

  FIG. 7 displays the peer link usage structure 700 and the failover matrix structure 710 calculated by the subsystem 100 of FIG. In this figure, these structures are filled in using the network A embodiment of FIG. 2 and the failure scenario embodiment in the failure structure 500 of FIG.

  Peer link usage structure 700 consists of a table with failure scenarios copied from failure structure 500 in each row. In addition, the first row shows a “no failure” scenario where the elements of the network have not failed. Columns indicate peering links. In this example, there are three peering links P1, P2 and P3.

  The input to each row / column is the Mb / s usage of the peering link under the failure scenario. If the peering link fails under a failure scenario, no number is entered. For example, failure scenario P2 is shown in the third row of table 700 and in FIG. In this failure scenario, network A reconfigures the route so that request DA2 passes through peering link P1, resulting in a total usage of P1 of 50 Mb / s from DA1 and 100 Mb / s from DA2. . Accordingly, since the total amount of use is 150 Mb / s, this is entered in the second column of the third row of the table 700.

  After the peer link usage structure 700 is calculated, the failover matrix composer 130 of the subsystem 100 of FIG. 1 calculates the failover matrix structure 140. Failover matrix structure 140 includes data corresponding to peer link usage structure 700.

The failover matrix structure 140 can be implemented as a table where each row represents a failure scenario and each row represents a peer circuit. In one example embodiment, any of the following can be used as input to individual matrices. That is,

1. Blank (when the corresponding peering link fails in the corresponding failure scenario). Or

2. A number equal to the percentage of traffic sent from all failed links in the row to the peering link. For example, under failure scenario P2, the 150 Mb / s traffic route from structure 700 that would normally pass P2 is reconfigured. Under failure scenario P2, the usage of P1 increases by 100 Mb / s, which is 67% of 150 Mb / s. Therefore, the input to 710 rows corresponding to the failure scenario P2 and the columns corresponding to the peer circuit P1 is 67%.

  FIG. 8 represents an embodiment of network B of FIG. 3 in a particular failure state. The embodiment for creating the required route setting structure of FIG. 9 will be described with reference to FIG.

  Network B 800 is the same network as that of FIG. In this figure, one of the nodes in the network, N8 (820), is indicated by a cross (X). This is the failure scenario shown in the table of structure 510 in FIG. The three requests DB1, DB2, and DB3 (801-803) originating from the network A are rerouted avoiding the failed node.

  FIG. 9 shows a request path configuration structure 900 that is calculated by the network calculator 160 of FIG. 1 using the failover matrix structure 140 and the fault structure 151, topology structure 152, and request structure 153 of the network B. .

  The request routing structure 900 includes a table for all failure scenarios in the failure scenario structure 151 and a table for normal network operation with no failing elements. This figure shows these two tables, namely the normal operation table 910 and the table 920 corresponding to the failure of the node N8, which is the single failure scenario shown in the failure structure 510 of FIG.

  Each of the 900 tables has a row for each request in the network and a column for each link in the network. What is entered in the table for a particular request and link is the amount of traffic for that request through that link.

  FIG. 10 is a flowchart describing a procedure according to an example embodiment implemented by the system of FIG. The flow starts at step 1000. In step 1010, the peer link usage structure 120 is configured by the peer link usage calculator 110 using the topology structure, requirement structure, and failure structure of network A. This process is further described in FIG.

  In step 1020, the peer link usage structure 120 is used by the failover matrix composer 130 to calculate the failover matrix structure 140. This process is also described later in FIG.

  In step 1030, network A sends failover matrix structure 140 to network B.

  In step 1040, network B receives failover matrix structure 140 from network A.

  In step 1050, network simulator 160 simulates the routing of requests in network B using the topology structure, request structure, and failure structure of network B along with the failover matrix structure. In this way, the request route setting structure 165 is configured. This process is also described later in FIG.

  In step 1060, the request structure 165 is used to display the network simulation via the GUI, and the network layout, route setting, and future are considered in consideration of the network operation described as the route setting. Propose to optimize the schedule and execute the optimization. FIG. 14 depicts a group of GUI elements that can display a network simulation while specifically enabling a simulation of a request from a peered network.

  At step 1070, the procedure ends.

  FIG. 11 is a flowchart describing a method for calculating the peer link usage structure 120 in the peer link usage calculator 110 of FIG. 1 according to an example embodiment. The process starts at step 1100.

  In step 1110, the peer link usage structure 120 is defined as a matrix U (i, j). Where i refers to the failure scenario and j refers to the peering link. i = 0 is for "no failure" during normal times. First, let U (0, j) be the link usage resulting from request routing under the “no failure” scenario for each j. The request route is set using any one of the route setting protocols (for example, IP route setting protocol) used by the network A. Each U (i, j) is set to 0 when i> 0. The index i is 1.

  In step 1120, the operation of the routing protocol used by network A as the usage resulting in the peering link U (i, j) for a given failure scenario i resulting in the routing of the request under failure scenario i. And the operation of this protocol in the event of encountering the failure described in this failure scenario again. If all of the peering links j fail in failure scenario i, let U (i, j) be "-" indicating that this link is not used at all.

  In step 1130, it is checked whether i is the last failure scenario of the failure structure in network A. If so, the process ends at step 1140 to obtain the required peer link usage table U (i, j). If not, i is incremented at step 1150 and control returns to step 1120.

  FIG. 12 is a flowchart describing a method for calculating the failover matrix structure 140 with the failover matrix constructor 130 of FIG. 1 according to an example embodiment.

  The process starts at step 1200. The peer link usage structure U (i, j) is defined with i = 0 when “no failure”.

  In step 1210, F (i, j) is set to 0 for all failure scenarios i and peering links j, and the initial value of i is set to 1. Then, F (i, j) is filled with the failover matrix structure 140.

  In step 1220, T (i) is the total usage of U (0, j) calculated for U (i, j) equal to “−”. This means that T (i) is the total amount of traffic that needs to be transferred from the peering link that fails under scenario i to another link. The initial value of the count value j of the peering link is 1.

  Step 1230 branches depending on whether U (i, j) = “−”. If YES, in step 1260 F (i, j) is set to “−”. If NO, in step 1240, F (i, j) is the increase in traffic on link i when the failure scenario is compared to the failure-free scenario, as a percentage of the total amount of traffic moved in T (i). It shall be expressed. That is, F (i, j) is expressed as a percentage (U (i, j) −U (0, j)) / T (i).

  Step 1250 branches depending on whether the last peering link j has been reached. If yes, control passes to step 1270. If not, j is added at step 1280 and control returns to 1230.

  Step 1270 branches depending on whether the last default scenario i has been reached. If yes, control passes to step 1295. If not, i is added at step 1290 and control returns to 1220.

  FIG. 13 is a flowchart describing a method for simulating network B 160 of FIG. 1 according to an example embodiment.

  From step 1300, the process starts. Define the failover matrix F (i ′, j ′) that is brought from network A to network B. This i 'refers to a network A failure scenario, and j' refers to a network A failure scenario.

  The request path setting structure 165 is represented by a ternary array D (i, j, k). Here, i indicates a failure scenario of network B, and i = 0 is a “no failure” scenario. J indicates a link of network B, and k indicates a request of network B.

  In step 1310, let D (0, j, k) be the amount that request k uses link j when network B is operating in normal time for each link j and each request k. When i> 0, all D (i, j, k) are set to 0. The initial value of the request index k is 1.

  In step 1320, the initial value of the failure scenario index i is set to 1.

  In step 1330, in failure scenario i, the request k branches depending on whether it will be rerouted to bypass the failed peering link. If not, then in step 1350, for this i, D (i, j, k) is the routed request in this failure scenario simulating the normal protocol used to route the request in network B. The amount of k used. If not, in step 1340, refer to the row i ′ representing the failure scenario i ′ of the network A in the failover matrix (i ′, j ′), and the peering link failure is being processed in the network B. Corresponding to the failure scenario i.

  In step 1360, the routing r (j ′, j) for request k is calculated for all links j in network B and for each peering link j ′ that does not fail in scenario i. At this time, it is assumed that a request to enter the network B passes through the link j ′, and a normal protocol is used for route setting in the network B. For each j ′, add r (j ′, j) × F (i ′, j ′) to D (i, j, k). That is, D (i, j, k) is routed so as to pass through all the peering links that have not failed at the same time with the ratio defined by the failover matrix structure 140. This ratio is the ratio at which traffic from a failed peering link to another peering link fails over.

  Step 1370 branches depending on whether the last failure scenario i has been reached. If yes, control passes to step 1380. If not, i is added at step 1375 and control returns to step 1320.

  Step 1380 branches depending on whether the last request k has arrived. If yes, control passes to step 1390. If not, control returns to step 1320.

  In step 1390, the required path setting structure D (i, j, k) is completed, and the flow ends.

  FIG. 14 is a graphical representation of a graphical user interface (GUI), according to an example embodiment. This GUI can be used to view the results of the network simulation performed by 160 of FIG. As an example, the network B of FIG. 3 is displayed. Since the operator of this network is fully aware of the topology of network B, all the nodes or routers shown as 1460, etc., and all circuits shown as 1420, etc., as described in box 1410 Thus, the topology of the network B can be completely displayed. In these two-way circuits, both links directed in each direction are shown side by side, and the direction of the arrow indicates the direction of the component link. Different colors can be applied to the air gaps within each link, for example, to indicate the total usage of a link under a particular failure scenario, or a request passes through that link under a particular failure scenario It may represent whether or not. It is also possible to display various failure scenarios by marking the failed elements on the GUI. In FIG. 6, for example, a failure scenario is expressed by attaching a cross 1440 to the node N8 that fails in this failure scenario.

  Also, the topology of network A is not known to network B. Only the peer circuit connected from network A to network B is known. In such a case, the network A can be expressed by being “compressed” into one node 1400. The peer circuit is represented by 1450 and is a circuit connected to the node 1400.

  Normally, a network can connect to many peer networks via peer connections. In this case, all peer circuits are displayed as two-way links. If such a peer circuit is displayed as if it is performed by a circuit (such as 1420) in the network B, for example, a large amount of display disturbance may occur on the screen displaying the network or its printout. There is. Therefore, the peer circuit is shown as a short circuit such as 1450, and the node in the network B connected to the peer circuit is represented by a single line (such as 1430) drawn from the tip of the circuit 1450 to the node. it can. Such a line expression makes it possible to completely eliminate the occurrence of display disturbance.

  FIG. 15 illustrates an example computer system 1500 using a schematic representation of a machine within which one or more of the methods described herein may be implemented. A set of instructions can be executed. In another embodiment, the machine may operate as an independent device or may be connected to other machines (eg, via a network). As a deployment in the network, this machine may serve as a server or client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. It may take on a function. Such a machine can be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), mobile phone, web application, network router, switch or bridge, or the machine takes It can be any machine that can execute a set of instructions that specify an action (either sequentially or otherwise). Although only a single machine has been described here, the term “machine” further refers to one or more sets of instructions, individually or in conjunction, for performing one or more of the methods described herein. Should be construed to include any collection of machines that perform.

  Examples of computer system 1500 include a processing unit 1502 (such as a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 1504, and a static memory 1506. Interconnected by a bus 1508. The computer system 1500 may further include a video display 1510 (eg, a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1500 also includes an alphanumeric input device 1512 (eg, a keyboard), a user interface (UI) navigation device 1514 (eg, a mouse), a disk drive device 1516, a signal generation device 1518 (eg, a speaker), and a network interface device 1520. .

  Disk drive unit 1516 includes machine-readable medium 1522 that stores one or more sets of instructions and data structures (eg, software 1524) that are implemented or utilized by one or more methods or functions described herein. It is out. When executed by the computer system 1500, the main memory device 1504, and the processing unit 1502 that also constitute the software 1524 itself, the machine readable medium, the main memory unit 1504 and / or the processing unit 1502 are fully Or at least part of it will be present.

  The software 1524 can perform transmission to the network 1526 or reception from the network 1526 via the network interface device 1520 using any well-known transfer protocol (for example, http).

  Although the machine readable medium 1522 is shown as a single medium in one example embodiment, the term “machine readable medium” refers to one or more media (eg, centralized) that store one or more sets of instructions. Database or distributed database, and / or associated cache and server). The term “machine-readable medium” also refers to any medium capable of storing, encoding, or carrying a set of instructions that are executed by a machine to perform any one or more methods according to the invention. Should be construed as including, or construed as including media that store, encode, or carry data structures utilized or associated with such a set of instructions. The term “machine-readable medium” is interpreted to include, but is not limited to, solid phase memory, optical and magnetic media, and carrier wave signals.

FIG. 1 is a block diagram showing the entire route setting exchange system. FIG. 2 represents an example model of network A used by an operator of network A. FIG. 3 represents an example model of network B used by network B operators. FIG. 4 represents two data structures used in the system of FIG. 1 for storing data used in creating and using a failover matrix structure. FIG. 5 represents the failure structure used by the system of FIG. 1 to describe failure scenarios associated with the configuration and use of the failover matrix. FIG. 6 is a display of an embodiment of network A of FIG. 2 in a particular failure state. FIG. 7 is a representation of an implementation model of the failover matrix structure. FIG. 8 is a display of an embodiment of network B of FIG. 3 in a particular failure state. FIG. 9 is a display of an embodiment of a route setting request structure. FIG. 10 is a flowchart describing an embodiment of the operation method of the system of FIG. FIG. 11 is a flowchart describing an embodiment of a method for calculating peer associations. FIG. 12 is a flowchart describing an embodiment of a method for calculating a failover matrix. FIG. 13 is a flowchart describing an embodiment of a method for simulating a network. FIG. 14 is a display of an example graphical user interface. FIG. 15 is a schematic representation of a machine in an embodiment of a computer system.

Claims (22)

A method of communicating information for predicting traffic behavior between interconnected networks , comprising:
Generating a network transfected topology structure data in which at least a portion of the topology of a first network is described,
And generating a request structured data of at least one traffic request is described relating to the destination of the transmission source and the second network in the first network, before Symbol said the first network between the second network there are multiple network links, and step,
Generating a traffic routing changes data described is one change scenarios even without least Ru potential Oh you need to change the traffic routing,
The network transfected topology structure data, the request structure data, and using said traffic routing change data, the for at least one change scenarios, the plurality of between the first network and the second network Calculating the routing of traffic through each of the network links;
And transmitting the modified data to the second network, before Symbol change data, the at least definitive to one change scenario, data movement is described in the network transfected traffic passing through said plurality of network links There is a step ,
A method comprising the steps of:   The method of claim 1, wherein the change scenario is at least one of a maintenance scenario and a failure scenario in which at least one of the network links is to be maintained or fails. Wherein the request structure data about the respective traffic request is claims, characterized in that the said source of the traffic demand, the destination of the traffic demand, and the size of the traffic demand is described The method according to 1. The network transfected topology structure data The method of claim 1, wherein the containing data describing a plurality of network link between the second network and the first network. Wherein the step of calculating the routing of traffic information on each of the change scenario, the traffic that is routed to pass through the respective other network link when one or more of the network links has changed Calculating a quantity ,
The change data, the at least one of about the change scenario is determined from the calculation of the routing of traffic through each of the plurality of network links between said first network said second network ,
The change data, with each of the change scenario, including an increase in the percentage of traffic that each Ru is the street routing of other network links one or more modified If Niso of said network links Yes ,
The method of claim 1 wherein: A system for communicating information for predicting traffic behavior between interconnected networks ,
To generate network transfected topology structure data in which at least a portion of the topology of a first network is described, and stores the network transfected topology structure data in a memory device, a network transfected Polo Gee module,
Generates a request structured data one traffic request is written even without least you related to the previous SL destination of the first source and before Symbol in the second network in a network, said memory device A traffic request module for storing the request structure data , wherein a plurality of network links exist between the first network and the second network ;
And generating at least one traffic route setting change data that changes the scenario described, storing the traffic route setting change data to said memory device, a traffic route setting change module,
The network topology structure data, the request structure data, and using said traffic routing change data, with the at least one change scenarios, the plurality of between the first network and the second network you calculate the routing of traffic through the respective network links, and calculator,
A transmission module for transmitting to the front Stories second network change data, the change data, in said at least one change scenario is the data movement is described in the network traffic passing through said plurality of network links , The sending module ,
A system characterized by comprising: Before SL change scenario, at least one of the is that the made or a failure to preserve or, alternatively, at least one node is to be preserved or failure of the second network before SL network link The system according to claim 6, wherein the system is at least one of a maintenance scenario and a failure scenario. In the change data, information necessary for the second network operator to change the traffic routing for a possible change scenario includes information other than the necessary information about the first network. 7. The system of claim 6, wherein the system is described without making it apparent to an operator of the second network . A method of communicating information for predicting traffic behavior between multiple networks ,
A first network change data from the first network, the method comprising: receiving at a second network, the prior SL first network change data, at least one network link variable in the further scenario, the first network and is described the movement of network transfected traffic through a plurality of links between the second network, the at least one network link change scenario, the plurality At least one of the links has changed , the step,
Generating a Ne Ttowa transfected topology structure data at least part of which is described in the topology of the second network,
A source in the first network, related to a destination in the second network, generating a request structured data of at least one traffic request is described,
And generating a second network change data in which at least one change scenario is described in the second network,
The network transfected topology structure data, the request structure data, the first network change data, and using said second network change data, at least before SL in the second network calculating a routing of traffic through the information on a single network link change scenarios, the second network,
A method comprising the steps of: The network link change scenario, at least one of the is that made or a failure to preserve one of the network link, or whether at least one node of said second network is to be preserved or The method of claim 9, wherein the method is at least one of a maintenance scenario and a failure scenario of failure. Wherein the first network change data, information necessary to the in-to the Possible network link change scenarios second network operator to change the routing of traffic, the first network wherein without information other than information required to clear the operator of the second network, characterized in that it is described, the method of claim 9 wherein about. The network topology structure data is characterized in that it comprises a data in which a plurality of nodes of the second network is described, the method of claim 9, wherein. A system for communicating information for predicting traffic behavior between interconnected networks ,
A first network change data from the first network, a receiving module for receiving at a second network, the prior SL first network change data, at least one network link in change scenario, the and the movement of the network transfected traffic is described through a plurality of links between the first network and the second network, the at least one network link change scenarios, the plurality of At least one of the link is changed, a receiving module,
The second at least a portion of the topology of the network generates a network transfected topology structure data described, storing the network transfected topology structure data in a memory device, a network transfected Polo Gee module,
And generates at least one request structure data traffic request is described related to the transmission destination of the transmission source and in the second network in said first network, said request structure data in said memory device A traffic request module for storing
The second second to generate a network change data in which at least one second network change scenario in the network have been described, changes the second network to the memory device A change module to store the data;
The network transfected topology structure data, the request structure data, the first network change data, and using said second network change data, the at least one second in the second network for network change scenarios, to calculate the routing of traffic through the second network, and the network simulator,
A system characterized by comprising: The network simulator, the at least one of the second network change scenarios claims, characterized in that simulate the routing of traffic through the respective multiple nodes of the second network Item 14. The system according to Item 13. Said traffic request module, wherein the source of the traffic demand, the destination of the traffic demand, and the size of the traffic demand is described, the request structure data about the respective said traffic requests to generate The system according to claim 13. The network topology module, the second multiple nodes of a network including data described the system of claim 13, wherein said network transfected topology structure data, characterized in that generate. By the network simulator, the second routing of traffic information on each of the network change scenario, the at least one second network change scenarios if the second network The system of claim 16, comprising calculating the amount of traffic that will be routed through each of the plurality of nodes. The network simulator, the the information on at least one second network change scenario, from the calculation for the routing of each through belt traffic of the plurality of nodes of the second network, before Symbol first the system of claim 17, wherein determining the second network change data. The network simulator, for each of the previous SL second network change scenario, if one or more nodes of the second network Ru is changed, so as to pass through the other nodes of the second network 18. The system of claim 17 , wherein the second network change data is determined to include an increasing percentage of traffic that is to be routed. The rate of increase, the system of claim 19, which is a ratio of the traffic that will be re-routed to the case of change scenarios. A graphical user interface module;
Said graphical user interface module, the network topology structure data, the request structure data, the first network change data, and using said second network change data, the graphical user interface the and displayed to the operator of the second network,
Said graphical user interface, the second all nodes of the network, as well as to display a plurality of link between the second network and the first network, before Symbol of the second network wherein not known to the operator does not display the first network details, and wherein the system of claim 13,. The graphical user interface is :
Is displayed along with two-way link between the nodes, and a plurality of nodes of the first network,
A said second network to be displayed as a compressed single node, said second network to be displayed in conjunction with a single line from the compressed node connected to said first network,
The system of claim 21 , comprising: