US20090196184A1 - Method and system for path identification in packet networks - Google Patents

Method and system for path identification in packet networks Download PDF

Info

Publication number
US20090196184A1
US20090196184A1 US12/423,392 US42339209A US2009196184A1 US 20090196184 A1 US20090196184 A1 US 20090196184A1 US 42339209 A US42339209 A US 42339209A US 2009196184 A1 US2009196184 A1 US 2009196184A1
Authority
US
United States
Prior art keywords
area
routing
cost
information
path
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US12/423,392
Other versions
US8218447B2 (en
Inventor
Rajendran Rajan
Roch Guerin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sons Of Innovation LLC
Original Assignee
IPTIVIA Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US12/423,392 priority Critical patent/US8218447B2/en
Application filed by IPTIVIA Inc filed Critical IPTIVIA Inc
Assigned to IPSUM NETWORKS, INC. reassignment IPSUM NETWORKS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GUERIN, ROCH, RAJAN, RAJENDRAN
Assigned to IPTIVIA, INC. reassignment IPTIVIA, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: IPSUM NETWORKS, INC.
Assigned to CIRCADENCE CORPORATION reassignment CIRCADENCE CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: IPTIVIA, INC.
Publication of US20090196184A1 publication Critical patent/US20090196184A1/en
Assigned to CIRCADENCE CORPORATION reassignment CIRCADENCE CORPORATION CORRECTIVE ASSIGNMENT TO CORRECT THE APPLICATION SERIAL NO. FROM 12/432,392 TO 12/423,392 PREVIOUSLY RECORDED ON REEL 022878 FRAME 0484. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT OF A METHOD AND SYSTEM FOR PATH IDENTIFICATION IN PACKET NETWORKS; INCLUDING U.S. PATENT APPLICATION 12/423,392.. Assignors: IPTIVIA, INC.
Priority to US12/853,467 priority patent/US8510468B2/en
Assigned to AUGUSTINE FUND, LP, CHARLES AND SARAH LAMPHERE, JTWRS, VAN VLISSINGEN PROFIT SHARING TRUST, SHOFFNER, JOHN, NANETTE O. LAMPHERE TRUST, ROBERT G. LAMPHERE TRUST DTD 5/13/93, CAROL W. ASHER REVOCABLE TRUST, CRAIG ASHER REVOCABLE TRUST, DAVID L. ASHER REVOCABLE TRUST, DLWS PARTNERSHIP, DONALD L. ASHER REVOCABLE TRUST, GABRIEL ASHER 2011 SUSMAN TRUST, HENRY ASHER 2011 SUSMAN TRUST, HOPE E. ASHER REVOCABLE TRUST, SARAH ASHER 2011 SUSMAN TRUST, WILLIAM ASHER 2011 SUSMAN TRUST, MATARAZZO, JOSEPH reassignment AUGUSTINE FUND, LP SECURITY AGREEMENT Assignors: CIRCADENCE CORPORATION
Application granted granted Critical
Publication of US8218447B2 publication Critical patent/US8218447B2/en
Priority to US13/964,447 priority patent/US20140143442A1/en
Assigned to MELTON, R. NEAL, C&S LAMPHERE INVESTMENTS, LLC, SHOFFNER, JOHN, MATARAZZO, DR. JOSEPH, DR., CRAIG ASHER REVOCABLE TRUST, HOPE E. KALINSKI REVOCABLE TRUST, GABRIEL ASHER 2011 SUSMAN TRUST, CAROL W. ASHER REVOCABLE TRUST, SILVERLEAF CONSULTING, LLC, VAN VLISSINGEN PROFIT SHARING TRUST, SAINTS CAPITAL IV, LP, AUGUSTINE FUND, LP, PASQUALE, JUDY, HART, STEPHEN, HARLAN, JOHN, DONALD L. ASHER REVOCABLE TRUST, JTWRS, CHARLES AND SARAH LAMPHERE, DAVID L. ASHER REVOCABLE TRUST, WILLIAM ASHER 2011 SUSMAN TRUST, SARAH ASHER 2011 SUSMAN TRUST, HENRY ASHER 2011 SUSMAN TRUST reassignment MELTON, R. NEAL SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CIRCADENCE CORPORATION
Assigned to CIRCADENCE CORPORATION reassignment CIRCADENCE CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: AUGUSTINE FUND, LP, C&S LAMPHERE INVESTMENTS, LLC, CAROL W. ASHER REVOCABLE TRUST, CRAIG ASHER REVOCABLE TRUST, DAVID L. ASHER REVOCABLE TRUST, DONALD L. ASHER REVOCABLE TRUST, GABRIEL ASHER 2011 SUSMAN TRUST, HARLAN, JOHN, HART, STEPHEN, HENRY ASHER 2011 SUSMAN TRUST, HOPE E. KALINSKI REVOCABLE TRUST, JTWRS, CHARLES AND SARAH LAMPHERE, MATARAZZO, JOSEPH, DR., MELTON, R. NEAL, PASQUALE, JUDY, SAINTS CAPITAL IV, LP, SARAH ASHER 2011 SUSMAN TRUST, SHOFFNER, JOHN, SILVERLEAF CONSULTING, LLC, VAN VLISSINGEN PROFIT SHARING TRUST, WILLIAM ASHER 2011 SUSMAN TRUST
Assigned to CIRCADENCE CORPORATION reassignment CIRCADENCE CORPORATION RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: AUGUSTINE FUND, LP, CAROL W. ASHER REVOCABLE TRUST, CRAIG ASHER REVOCABLE TRUST, DAVID L. ASHER REVOCABLE TRUST, DLWS PARTNERSHIP, DONALD L. ASHER REVOCABLE TRUST, GABRIEL ASHER 2011 SUSMAN TRUST, HENRY ASHER 2011 SUSMAN TRUST, HOPE E. ASHER REVOCABLE TRUST, LAMPHERE, JTWRS, CHARLES AND SARAH, MATARAZZO, JOSEPH, NANETTE O. LAMPHERE TRUST, ROBERT G. LAMPHERE TRUST DTD 5/13/93, SARAH ASHER 2011 SUSMAN TRUST, SHOFFNER, JOHN, VAN VLISSINGEN PROFIT SHARING TRUST, WILLIAM ASHER 2011 SUSMAN TRUST
Assigned to RUNWAY GROWTH CREDIT FUND INC. reassignment RUNWAY GROWTH CREDIT FUND INC. SECURITY INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CIRCADENCE CORPORATION
Assigned to SONS OF INNOVATION LLC reassignment SONS OF INNOVATION LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CIRCADENCE CORPORATION
Adjusted expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/03Topology update or discovery by updating link state protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • H04L45/123Evaluation of link metrics
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/26Route discovery packet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N11/00Colour television systems
    • H04N11/04Colour television systems using pulse code modulation
    • H04N11/042Codec means
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/184Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being bits, e.g. of the compressed video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/186Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component

Definitions

  • the present invention relates generally to a method and system for acquiring information from a packet communications network. More particularly, the present invention relates to a method and system for determining the set of links and routers that are traversed by traffic to and/or from an individual user of a packet communications network.
  • IP Internet protocol
  • connection-oriented such as frame relay or asynchronous transfer mode (ATM)
  • ATM asynchronous transfer mode
  • IP networks because routing decisions are made in a distributed fashion by many routers that are only concerned with local packet forwarding decisions, there is no single entity with complete knowledge of the entire path that a packet will follow at any given time. Again, this makes it more difficult for a network administrator to precisely identify the path that the traffic between, for example, two customer sites, is following when traversing the network.
  • MIBs Management Information Bases
  • SNMP Simple Network Management Protocol
  • MIBs provide detailed state information about individual routers, e.g., interface status, number of packets or bytes transmitted and received on each interface, etc. However, this information is local to each device, and does not offer a network wide perspective. Furthermore, piecing together MIB information from multiple routers to derive end-to-end performance measures of relevance to a given customer is not an easy task.
  • the Internet is a global network that consists of multiple interconnected smaller networks or Autonomous Systems (AS).
  • AS Autonomous Systems
  • the delivery of packets across this Interconnection of Networks is carried out under the responsibility of the IP suite.
  • routing protocols disseminate information that allows distributed decisions to be made on how best to forward packets towards their destination.
  • Internet routing protocols can be divided into intra-domain and inter-domain protocols, with inter-domain protocols communicating information between ASs, while intra-domain protocols are responsible for determining the forwarding of packets within each AS.
  • This general architecture and the associated suite of protocols are rapidly becoming the de facto technology on which modern communication networks are built. This dominance extends from simple local area networks to large-scale, international carrier networks, and is largely due to the robustness and efficiency of networks built using it.
  • IP networks are often referred to as “connectionless”, and the delivery of data packets to their intended destination is performed through a number of “independent” decisions made by the routers to which a packet is being forwarded.
  • a method of identifying a path of travel for a packet in a multi-area domain operated according to a link state routing protocol includes the step of receiving topology information from a plurality of individual areas in a domain. It also includes the steps of identifying a plurality of intra-area least cost paths from the topology information, and assembling a subset of the plurality of intra-area least cost paths into an end-to-end path between a starting address and a destination address.
  • Each least cost path preferably comprises a series of routers, with links or networks between routers.
  • the identifying step at least one exit point from the first area through which the destination address is reachable is identified, at least one least cost path segment within the first area between the starting address and at least one of the exit points is constructed, and at least one of the least cost path segments is selected to result in at least one selected first area least cost segment.
  • the exit point from first area may be the destination address.
  • the identifying step may also include identifying all exit points from the first area through which the destination address is reachable.
  • the identifying step may also include the step of, for at least one of the exit points associated with at least one of the selected least cost path segments, identifying a second area within the domain to which said at least one exit point is connected.
  • the identifying step may also include the steps of identifying at least one exit point from the second area through which the destination address is reachable, constructing at least one least cost path segment within the second area between the at least one exit point of the first area and at least one exit point of the second area, and selecting at least one of the least cost segments within the second area to result in at least one selected second area least cost segment.
  • the assembling step may include connecting one of the selected first area least cost segments and one of the selected second area least cost segments.
  • the exit point of the second area may be the destination address.
  • each constructing step may include constructing all possible least cost path segments, and the assembling step may include connecting a plurality of the least cost path segments between the starting address and the destination address.
  • Any or all of the method elements described above may be embodied in instructions, contained on a computer-readable carrier, that are capable of instructing a computing device to perform the elements.
  • a method of storing historical routing information in a routing domain operating according to a link state routing protocol includes the steps of storing a plurality of routing events advertised in a routing domain as they are received over time, and identifying a set of time instants for which a complete context of routing and topology information of the routing domain will be maintained.
  • At each time instant identified in the identifying step at least one time-stamped routing information context is constructed by storing data structures representing current topology and routing states of the routing domain.
  • a time ordered list of routing events is constructed as the events are received over time until the next time instant identified in the identifying step.
  • the routing domain may be a multi-area routing domain
  • the time-stamped routing information contexts may logically be partitioned through the separate storage of information pertaining to each area in the routing domain
  • the constructing step may include constructing a separate time ordered list of routing events for each area in the routing domain.
  • the embodiment described in the previous paragraph may include the step of specifying a starting point in the routing domain, a destination address in the routing domain, a starting time, and an ending time. It may also include the steps of reviewing the time-stamped routing information contexts to identify the context one having a time stamp that is latest yet still precedes contexts with a time-stamp preceding the starting time, and constructing at least one updated time-stamped routing information context by sequentially processing routing events from the time ordered list of routing events associated with the time-stamped routing information context until reaching the last routing event having a time-stamp that that precedes the starting time. It may also include the step of constructing path information between the starting point and the destination address using the updated time-stamped routing information context.
  • a method of identifying a path between a starting address and a destination address in a routing domain operated according to a link state routing protocol includes the steps of specifying an ordered list of routing events, providing a routing information context representing a starting topology and a routing state of a routing domain, constructing path information between a starting address and a destination address using the routing information context, updating the routing information context in accordance with a next routing event in the ordered list of routing events, and repeating the constructing and updating steps above until reaching a last routing event in the ordered list of routing events.
  • FIG. 1 illustrates an exemplary AS, or routing domain, where the present invention may be applied, including various elements of the AS such as areas, routers, route acquisition modules, a route aggregation module, an a route query module.
  • FIG. 2 illustrates exemplary steps that may be performed by a route acquisition module to gather topology information from an individual area in accordance with the present invention.
  • FIG. 3 illustrates the types of information and memory areas that may be allocated by a route aggregation module.
  • FIG. 4 illustrates the address information that may be used in order to identify specific routers, entry points, and/or exit points in an area.
  • FIG. 5 illustrates a preferred data structure of route association data received from multiple areas of an autonomous system in accordance with the present invention.
  • FIG. 6 is an example of an area-level map showing known boundary routers and known border routers for an autonomous system or routing domain.
  • FIG. 7 illustrates an example of a raw advertisements table comprising a collection of information gathered by route acquisition modules.
  • FIG. 8 illustrates a preferred embodiment of a structure of a context access tree that illustrates the format of the data structures used to capture the evolution of the network state over time.
  • FIG. 9 illustrates, in flowchart form, a preferred embodiment of the method of processing a query for a route identification in accordance with the present invention.
  • FIG. 10 illustrates an exemplary routing domain containing a starting point, destination addresses, multiple areas, and multiple routers within each area.
  • a preferred embodiment of the present invention provides an improved method and system for monitoring, tracking, and/or predicting the routing path of one or more packets under an IP protocol.
  • the present invention allows a network administrator, network monitoring system, or other human or automated user to identify the path or paths followed or expected to be followed by any packet traveling though an AS, where the packet has a known entry point or address and a known or anticipated destination address.
  • the destination address is associated with a routing entry, typically from a routing table, and the present invention constructs the path that was or is expected to be followed through the routing domain by the packet associated with the routing entry.
  • the invention is capable of constructing the complete set of possible paths, any of which the packet may follow.
  • FIG. 1 illustrates an exemplary AS, or routing domain, where the present invention may be applied.
  • the domain illustrated in FIG. 1 is not, of course, the only domain configuration in which the invention may apply, but it is only intended to serve as an illustration of one possible domain.
  • the illustrated AS includes three areas 10 , 11 , and 12 .
  • the present invention may also be used with an AS having more than three or fewer than three areas.
  • the AS such preferably follows a link state routing protocol such as open shortest path first (OSPF) or ISIS.
  • OSPF open shortest path first
  • ISIS ISIS
  • border routers 21 which serve as routers for two or more areas within the AS and provide for the passage of traffic from one area 11 to another area 10 and vice-versa; and (3) boundary routers 22 , which serve as exit and/or entry points to and from the AS.
  • the AS includes one or more Route Acquisition (RAQ) modules 15 , 16 , and 17 .
  • RAQ Route Acquisition
  • the RAQ modules which preferably have the features of a routing device, essentially serve as “stub-routers” and participate in the routing protocol of their respective area. This allows them to receive much or all of the routing information exchanged between routers in their area. In the context of a link state protocol, this information provides detailed background about the internal topology of the area, the set of addresses associated with the different routers in the area and the current state of various network nodes and interfaces. It may also provide summarized information regarding destinations in other areas and outside the AS, or how to reach them.
  • the exact structure and specification of the information received by the RAQ module depends on the routing protocol in use, but a key feature is that it provides information about the “cost” of reaching local destinations inside the area, as well as remote destinations through different “exit” points from the area.
  • the “cost” refers to the distance that a packet must travel to reach a destination from a starting point.
  • the cost may be directly related to a number of “hops” between routers. For example, referring to area 11 in FIG. 1 , if the cost of traveling between each router were, for example, one, then the cost for a packet to travel from RAQ module 15 to router 21 via router 20 would be two, since it takes two “hops” to reach the destination: a first hop to router 20 and a second hop to router 21 . Alternatively, if the cost of the link between router 21 and router 20 were, for example, three, then the total cost for the packet to travel from RAQ module 15 to router 21 through router 20 would be one plus three, which is four.
  • the AS also includes a Route Aggregation (RAG) module 18 .
  • RAG Route Aggregation
  • One RAG module is the default configuration, but more than one RAG module is a possible option.
  • the RAG module 18 receives and processes the information obtained by the RAQ modules, and is described in more detail below.
  • the RAG module 18 may be any computing device, such as a PC, laptop, server, or individual work station having a processor and memory.
  • the RAG module 18 is in substantially constant communication with many, and preferably all, of the RAQ modules in the different areas of its AS.
  • the RAG module receives from the RAQ modules the routing information that the RAQ modules have acquired through participating in the routing protocol of their individual area.
  • the RAG module parses and processes this information to support the extraction of end-to-end (across the AS) path information, even across multiple areas.
  • the RAG module performs a key function, as the routing information from individual routers typically only provides local path information specific to individual areas.
  • the RAG module structures the routing information associated with different areas so as to facilitate its piecing together to create end-to-end paths in response to route queries.
  • the RAG module 18 includes a component referred to herein as the route storage sub-module (or, more briefly, the “storage module”).
  • the storage module maintains information gathered by the RAG from the RAQs, both current and historical. Thus, the storage module is preferably sufficient to store a large quantity of information received from the RAQ modules. However, RAGs with smaller memory amounts can be used.
  • historical information can be stored in raw (i.e., unprocessed) form or supplemented with one or more indices, tables, and/or summaries to enable rapid retrieval of historical state. This information can be used for both a playback, or path analysis, function and a play-forward, or predictive, function, each of which is described in more detail below.
  • the AS also includes at least one Route Query (RQ) module 25 that serves as an interface for a user, such as a network administrator, to retrieve information collected by the RAG module.
  • the RQ module 25 may be a separate device, such as a computing device having an input/output port or communications port, or it may be co-located with another device.
  • FIG. 1 illustrates the RAG module 18 and the RQ module 25 as being installed on a single computing device.
  • any or all of the modules described above can be considered functional units, and two or more of them may be co-located in the same physical device.
  • the RQ module 25 interfaces to the RAG module 18 and coordinates the process of retrieving complete path information from the data structures maintained by the storage module.
  • the RQ module 25 accepts as inputs an identifier for the starting point within the AS for a path or route that is to be retrieved, and an identifier for the end point or destination for the path.
  • the identifier of the starting point can be a host name or IP address local to the AS, i.e., belonging to one of the subnets in the AS, or be in the form of an interface number belonging to one of the routers in the AS, i.e., identifying the entry point into the AS.
  • the identifier of the desired end-point or destination will typically be in the form of a host name or IP address, and need not be associated with a device that is local to the AS.
  • the path information that is returned extends from the (local) entry point in the AS to the exit point from the AS towards the next AS that is to be used in order to reach the remote destination.
  • the RQ module 25 may also accept a time parameter to identify whether the information to be provided is a playback (i.e., analysis of a path previously traveled) or play-forward (i.e., predictive) response.
  • the RQ module may also accept additional events pertaining to “what-if” scenarios.
  • the optional time parameter (which typically is coordinated with or relates to a clock associated with the RAG module) would identify the time at which state dynamics are sought to be represented. If the time indicated is in the future, additional events, identified as a sequence of (time, network element, state) may be accepted as input by the RQ.
  • a RAQ module essentially serves the function of a “stub-router” that participates in the routing protocol of its own area. There will typically be one RAQ per area, although more than one could be deployed for redundancy purposes.
  • topology i.e., structure of an area such as router addresses and cost between routers
  • route information is flooded through each area, so that each router acquires a complete topological real-time map of its area and of the location of route entries.
  • routers connected to other areas or other ASs i.e., border routers ( 21 on FIG. 1 ) and/or boundary routers ( 22 on FIG.
  • the information may be as simple as stating that they can reach destinations in other areas (as would be the case in a domain following the ISIS protocol), or it may include the identity of the routing entries they have learned, the cost associated with reaching those routes when going through them, and/or other information items (as would be the case in a domain following the OSPF protocol).
  • Routers inside an area use this information to determine how to forward packets along shortest paths towards the route entry that matches the packets' destination address.
  • FIG. 2 illustrates exemplary steps performed by a RAQ module in accordance with the present invention.
  • each RAQ module receives all updates pertaining to changes in routing and topology information (step 30 ).
  • the RAQ is then responsible for making that information available to the RAG. Specifically, the RAQ receives information transmitted by its neighboring routers within the area and uses that information to build a topology database.
  • the RAQ module checks the topology database to determine whether the information is new (step 32 ). If the information is not new, the RAQ module does nothing with the information (step 34 ) and watches for additional information (repeating step 32 ). If the update corresponds to new information, then the RAQ module updates its topology database with the new information (step 36 ), and it also forwards the updated or new information to the RAG module (step 38 ).
  • the RAG module maintains a global topology database that contains information received from all RAQ modules in the AS with which it communicates.
  • the topology database that the RAQ module builds provides it with substantially complete knowledge about routers and links (and their cost) in the RAQ module's own area, as well as possibly route entries reachable within and outside its own area or the identity of routers capable of reaching remote entries.
  • the RAQ module is preferably any type of routing device that may be commonly found or used in the AS or in a comparable AS.
  • the RAQ module is not required to forward transit data.
  • the particular RAQ module used optionally can be one of relatively low-end technology.
  • the RAG module 18 collects and manages information assembled from the various RAQ modules 15 , 16 , and 17 into a form that is easily queried by the RQ module 25 .
  • the preferred embodiment described herein assumes that there is one RAG serving a given routing domain.
  • the RAG maintains a number of data structures used to store and organize the information it receives from RAQs in different areas.
  • FIG. 3 illustrates the preferred types of information that may be received and memory areas that may be allocated by the RAG module.
  • the RAG 39 maintains at least two sections or types of memory.
  • the information includes two types of contexts. One context corresponds to the current routing domain state, while others are associated with past routing states.
  • the first type, a Contextual Information Structure (CIS) 40 represents a snapshot of the routing state of the network at a particular instant, and can be searched to provide end-to-end (through the routing domain) path information in response to queries placed by the RQ module.
  • CIS Contextual Information Structure
  • the past routing states together with raw-data received from the RAQs, processed event indices, and other structures pertaining to the past dynamics of the network, make up the historical information that the RAG maintains in the second type of memory, a historical information structure (HIS) 46 .
  • HIS historical information structure
  • the RAG module has two roles. In its downward-facing (or AS-inward) role, it communicates with the RAQs and assembles the updates that it receives from the RAQs. In its upward-facing (or AS-outward) role, the RAG module creates and deletes CISs in response to requests from the RQ module.
  • Each CIS includes at least one, and preferably several, several area data structures (ADS) 42 , each with a corresponding route association data (RAD) structure 44 .
  • the CIS pieces together information received from different RAQ modules so that the information can be searched to provide end-to-end (through the routing domain or AS) path information in response to queries placed by the RQ module. This piecing together is achieved through a topology map that identifies how the different area data structures are linked together in the AS.
  • Each ADS is essentially a replica of the area's topology database constructed in a manner essentially similar to how routers construct their own area topology database. This is made possible by the fact that the RAQs ensure that any update they receive is communicated to the RAG.
  • the RAG receives all relevant updates from each area and uses them to reproduce the area topology databases that are separately maintained in each area by the RAQ for the area.
  • Each topology database contains a list of all the routers in the area together with their links and networks, as well as adjacencies, i.e., the set of routers reachable through a given link or network.
  • the information available from an area database allows the computation of shortest paths between any pairs of routers or interfaces in the area.
  • the ability to associate those shortest paths with route entries, and therefore destination addresses, is provided through the RAD structure 44 .
  • the RAD 44 is similar to the routing table that is maintained by each router, with the difference that instead of storing the set of next hops associated with the shortest paths computed by the router for each routing entry, the information that is kept is the identity of the router from which the route was learned.
  • a primary function of the RAD is to maintain knowledge of which router a given route entry is associated with.
  • a route entry is said to be associated with a router if the router is one that “advertised” reachability to the route entry.
  • each router is associated with, or “advertises,” a list of routes that are reachable from the router.
  • router 51 advertises both: (1) “area internal” routes, or routes associated with networks directly reachable from the router; and (2) “area external” routes, or, routes associated with networks located in other areas or routing domains.
  • Route entry 48 . 13 . 4 . 0 / 24 which is advertised by router 51 , is an example of an area internal route.
  • Route entry 173 . 58 . 0 . 0 / 16 also advertised by router 51 , is an example of an area external route.
  • association of a router with an area external route does not necessarily require an explicit advertising by the router that it can reach the route entry. It is possible for such an association to be implicit, i.e., the router is known to be associated with area external route entries.
  • the RAD consists of a binary tree structure, such as a Patricia Trie (see FIG. 5 ) or an Adelson-Velskii-Landis (AVL) binary tree, that is commonly used in routers to allow the searching of route entries and retrieval of the entry that provides the longest prefix match for a given destination address.
  • the RAD is built as updates are received from the RAQs. Preferably, all the route entries received in an update are inserted in the RAD, although fewer than all may be inserted in alternate embodiments. If the route entry is already present, the router that originated the update through which the route entry was learned, or which in general becomes known as being associated with the route entry, is added to the set of routers with which the route entry is associated. If the route entry is not yet present in the tree, a new entry is created in the tree, and the set of routers with which the route entry is associated is initialized with the corresponding router.
  • the inverse process is followed, i.e., the tree is searched for the route entries that are to be withdrawn and the router that issued the withdrawal is removed from the list of routers associated with the route entry.
  • the entry is either deleted or marked as inactive. The inactive marking is useful when it is likely that the route entry will be added again in the near future.
  • FIG. 5 illustrates the structure of a RAD implemented using a Patricia Trie.
  • the structure includes the routing entries that are known for an area, as well as the routers that are known to be associated with (i.e., capable of reaching) each routing entry. Route entries are stored at the leaves of the Trie and include the list of routers associated with them.
  • the nodes of the Trie illustrate exemplary bit positions. For example, FIG. 5 illustrates an example where route entry 173 . 58 . 0 . 0 / 16 is advertised in the area by both routers 51 and 52 (of FIG. 4 ), and as a result the identity of the two routers is included in the entry kept for 173 . 58 . 0 . 0 / 16 .
  • the RAG module also keeps a data structure, a topology map that provides information needed to determine how the different areas are connected to each other, and for identifying routers that provide connectivity to outer routing domains. This information is readily obtained by identifying routers that advertise the ability of reaching routes in other areas or outside of the AS. Based on that information, the RAG constructs an “area-level” map of its routing domain, which is a high-level map showing only routers connecting areas or connecting to other routing domains. An example of such a map is shown in FIG. 6 .
  • the combination of area-level topology and per area detailed topology maps provides the RAG with complete knowledge for determining the set of (shortest) paths actually followed by packets when crossing the routing domain.
  • the RAG also keeps track of past routing states so as to be able to respond to path queries that pertain to time instants in the past. As mentioned earlier, this information is kept in a portion of memory referred to herein as the RAG Historical Information Structure (HIS).
  • HIS RAG Historical Information Structure
  • Historical information is useful to support “playback” queries used to identify how paths evolved in response to past changes in the network routing state.
  • the information maintained for this purpose consists of a Raw Advertisements Table (RAT) that includes all updates gathered by the RAG from the RAQs, as well as a Context Access Tree (CAT) that organizes a combination of contexts and updates into a tree structure for easy recovery of past network dynamics.
  • the RAT is a fairly simple structure that keeps a list of events received from various RAQs. It organizes updates based on the time received, the RAQ and area from which the message originated, the network node that originated the advertisement, as well as the raw update itself.
  • An exemplary RAT is illustrated in text form in FIG. 7 .
  • the CAT is a more complicated structure.
  • An exemplary CAT is illustrated in FIG. 8 .
  • the CAT comprises a timeline with various nodes 60 , 61 , 62 , and 63 , each of which contains a contextual information structure (CIS) such as 66 and 68 corresponding to a snapshot of the network at a point in time.
  • CIS contextual information structure
  • Linked to each component of the CIS is a time-ordered lined-list of events such as 67 and 69 , each of which corresponds to an update that caused a change in the state of the component.
  • This hybrid structure i.e., the combination of raw information and complete routing state as maintained in the CISs at different time-instances, provides an efficient trade-off between minimizing the amount of information that needs to be stored and allowing for the rapid reconstruction of the CIS associated with any given time instant in the past.
  • the RAG is able to answer queries that pertain to any given routing state, both present and past.
  • the initiation of queries is performed through the RQ module described below, which is responsible for accessing the different data structures maintained by the RAG.
  • the RQ module is responsible for returning a complete, end-to-end path, or set of such paths, in response to a route query specifying a starting point or origin in the routing domain and a destination address, possibly located outside of the routing domain.
  • the RQ module is capable of answering two different types of route query—instant queries and persistent queries.
  • Instant queries require single-shot responses in the form of a complete, end-to-end path or set of paths.
  • Persistent queries seek to track the dynamics of a complete, end-to-end path or set of paths over time.
  • There are multiple types of persistent queries based on the conditions under which path dynamics are to be tracked. We distinguish between standard persistent queries, playback persistent queries, and play-forward persistent queries. Additional types of queries are possible, but are not required to practice the present invention.
  • a standard persistent query is similar to an instant query with the one difference that the query is to be persistently reissued each time a routing update is received (at the RAG) that has the potential to affect the path or set of paths that was previously returned.
  • a standard persistent query tracks the evolution of a path or set of paths over time, as events, e.g., link or router failures, affect the routing state in the routing domain.
  • a playback persistent query specifies a starting time in the past and its goal is to track the evolution of a path or set of paths from that point on over a given period of time. In the context of a playback query it is then possible to step through events that have occurred over a period of time in the past, and for each identify which impact, if any, it had on the path or set of paths that were initially in effect.
  • a play-forward persistent query is similar to a playback query in that it specifies a starting time, possibly in the past, and requires stepping through a set of events in order to identify their impact on the path or set of paths that were initially returned.
  • the main difference between a play-forward query and a playback query is that with a play-forward query, the set of events that are to be used can be specified as part of the query, in order to allow experimenting with different “what if” scenarios and their impact on routing.
  • the structure of the RQ module is optionally and preferably much simpler than that of the other modules.
  • the RQ only needs to maintain path structures that have been returned in response to previous queries, although maintenance of other information is possible but not necessary to practice the present invention. Specifically, for each active query session the RQ keeps both (1) the information that was initially provided when the query was first issued, and (2) all subsequent path structures that were returned in response to the query. In the case of an instant query, this consists of only the origin that was specified for the path, the desired destination address, and the path or set of paths that were returned by the RAG. In the case of a persistent query, the RQ needs to also maintain all intermediate path structures that were returned in response to events that affected the original path structure. The set of events that were considered also needs to be kept.
  • the RAQ initialization has two parts. The first is essentially the initialization phase, such as that which may be followed by a typical router in the routing domain. It consists of a device level initialization followed by a set of procedures aimed at ensuring that all routers in a given area of the routing domain have consistent routing information. In the case of a RAQ that acts as a stub router, this will amount to providing its own routing information to its neighboring router(s) and acquiring its (their) routing information. The second part of the RAQ initialization is concerned with the establishment of a communication channel with a RAG and with the initial exchange of routing information with it.
  • the RAQ first retrieves, e.g., from a configuration file, the address of the RAG with which it needs to communicate and proceeds to initialize their communication channel. Once this step has been carried out, and assuming that the first part of the RAQ initialization has completed, i.e., it has acquired stable routing information, the RAQ initiates the transfer of its topology database and associated data structures to the RAG. The RAQ initialization terminates after this next step.
  • the RAG initialization is also carried out in multiple phases.
  • the first phase consists of device initialization and the creation of global data structures associated with the routing domain for which the RAG is responsible. It also includes the initialization of the procedures needed to enable future communications between the RAG and the different RAQs in the routing domain. For example, this can mean listening on a well-known port number or registering for notification of certain event types.
  • the RAG is ready to receive information from the RAQs and will go through additional initialization procedures each time it discovers a new RAQ.
  • the initialization procedures associated with the discovery of a new RAQ include the creation of the corresponding area data structures described in the description of the RAG above.
  • the RAG creates a new area structure and also updates its routing domain level structure to reflect the existence of the new area. Information regarding the area's internal topology and overall connectivity in the routing domain is then added as it is received from the RAQ. This second phase completes after the RAQ finishes communicating its initial routing and topology information to the RAG.
  • the RQ initialization procedures are optionally and preferably relatively minimal. Preferably, they include little more than contacting the RAG(s) associated with the routing domains the RQ is serving and retrieving from them relevant information that needs to be made available through the RQ User Interface. The identification of the relevant RAG(s) is typically provided through local configuration.
  • Routing (and topology) updates are transmitted by the RAQs to the RAG and are responsible for ensuring that the RAG maintains accurate information regarding the routing state of its routing domain.
  • a RAQ determines that it needs to forward a routing update to the RAG whenever it itself receives an update (internal or external) that results in the modification of its own topology database. The resulting change must then be communicated to the RAG, which triggers the generation of a routing update by the RAQ.
  • the RAG Upon receipt of the routing update, the RAG first identifies the area with which it is associated. This information is available through association with the identity of the RAQ that transmitted the update. Once the relevant area has been identified, the RAG accesses the corresponding CIS and proceeds to modify it in order to reflect the changes advertised in the routing update.
  • the nature of the changes required depends on the nature of the routing update.
  • the changes may range from the modification of an existing data structure or field, to the deletion of an existing data structure, to the creation of a new data structure.
  • a routing update that advertises a new cost for a link will result in the corresponding value being modified in the ADS.
  • a routing update associated with the deletion or failure of a link or a router will result in the removal of the corresponding data structures of fields in the ADS.
  • a routing update associated with the introduction of a new link or a router will result in the creation of data structures necessary to represent those new entities in the ADS.
  • the RAD will also be correspondingly modified.
  • a link or interface failure it may be necessary to remove the attached router from the list of routers through which any associated route entry is reachable. For example, a router that loses connectivity to a given subnet must be removed from the list of routers associated with the route entry corresponding to the subnet, and if the router was the last one in the list, the route entry needs to be marked as unreachable or deleted.
  • the case of a router failure is similar even if it typically requires more changes.
  • the receipt of a routing update also affects the HIS at the RAG. Specifically, any received routing update should be added to one of the link lists of events maintained for the last CIS stored in the CAT, as well as to the RAT that keeps track of all the routing events received by the RAG.
  • the receipt of a routing event can also trigger the storage of a new CIS in the CAT.
  • CISs may be stored in the CAT at regular time intervals, or after a given number of routing updates have been received, or according to some combination of those two criteria. In particular, imposing an upper bound on the number of routing updates that can be linked to a given CIS stored in the CAT is desirable to ensure that the CIS associated with an arbitrary time instant can be reconstructed within a reasonable amount of event processing.
  • the operation of the RQ module on the arrival of a query can be decomposed into a query initialization phase followed by a set of area specific steps and cross-area steps and is described in FIG. 9 in a flowchart format.
  • the query initialization phase includes the following steps: Step 100 : The system Determine if the appropriate CIS exists for handling the query. Step 102 : If the appropriate CIS does not exist, the RAG creates it. Step 104 : The RQ module identifies the source area associated with the starting point or origin of the path. Step 106 : The RQ module identifies the origin router associated with the starting or entry point of the path in the source area. Optionally, more than one entry point may be considered.
  • Steps 100 and 102 come into play in the context of playback or play-forward queries that may not start from the current CIS, but which require the extraction of a CIS corresponding to the time instant from which the playback or play-forward scenario is to start.
  • step 102 is accomplished by retrieving the necessary information from the HIS maintained at the RAG.
  • the first step in this process consists of searching the CAT to identify the CIS with the latest time preceding the time instant from which the query is to start.
  • the CAT is searched until a CIS is found that represents the full state of the routing domain at the latest time instant prior to the query starting time. Once the corresponding CIS has been identified, the list of routing events attached to the CIS is processed until all events anterior to the query starting time have been accounted for.
  • the resulting CIS describes the routing state of the routing domain, as it existed at the specified starting time of the query. For example, when referring to FIG. 8 and assuming a desired query starting time of 03 : 40 : 00 on Sep. 26, 2001, the search of the CAT would terminate at the CIS that was stored at 03 : 33 : 36 . 45 on Sep. 26, 2001, as it corresponds to the last CIS stored prior to 03 : 40 : 00 on that day.
  • this CIS does not represent the correct routing state at the desired query starting time.
  • step 104 of FIG. 9 returns Area 70 of FIG. 10 as the source area for the specified origin point “S” 74
  • step 106 of FIG. 9 identifies router 76 (of FIG. 10 ) as the starting point for paths that are to be returned in response to the route query.
  • Step 108 Optionally and preferably, the shortest path segment from the entry point or points will be initialized to a null value.
  • Step 110 Identify the route entry associated with the specified destination address.
  • Step 112 Identify the exit points in the area that are associated with (i.e., that can reach) the route entry.
  • Step 114 Compute shortest paths between the entry point or points and all exit points identified in step 112 . If multiple shortest paths are available, preferably all such shortest paths are identified in this step. If multiple shortest paths have been identified, then the system selects those that are viable for reaching the destination address (step 116 ).
  • step 118 the system combines those with the paths determined in step 116 (step 118 ) and identifies the combinations that terminate in the current area and/or are associated with area local exit points (step 120 ).
  • the system then returns the paths that are complete (step 122 ) and checks to see if there are other paths (i.e., other areas) that need to be checked (step 124 ). In cases where the destination address lies either in another area or in another routing domain, additional areas may have to be traversed before a complete set of paths is returned. If there are no other areas, then the path or paths have been identified and the process ends (step 130 ), typically by returning a report of the shortest path or paths. If another area or areas need to be checked, the system identifies the next area or areas (step 126 ), identifies the entry point for each such area (step 128 ), and repeats the process from step 110 .
  • steps 110 , 112 , 114 and 116 The purpose of steps 110 , 112 , 114 and 116 is to compute, within a particular area, shortest paths between the specified origin point and all the routers through which the destination could ultimately be reached.
  • the route query typically terminates at this point.
  • the destination address is associated with an “area-local” route entry, i.e., a route entry associated with a network directly attached to one or more of the area routers
  • the RQ determines that all shortest paths between the specified origin and the destination address lie within the area.
  • An exemplary identification of shortest paths within an area can be found in FIG. 10 . For example, referring to FIG.
  • step 114 of FIG. 9 above would return two shortest paths, namely, S-R4-R5-D1 and S-R4-R6-D1. Since address D1 is “local”, i.e., both R 5 and R 6 are connected to subnet 133 . 40 . 15 . 0 / 24 , the query process would stop there and those two paths would be returned.
  • destination address 90 ( 134 . 34 . 21 . 142 ) that is associated with a local route entry in area 72 , i.e., a different area than that of the origin of the route query (area 70 ).
  • the Route Query process starts by returning route entry 134 . 34 . 21 . 0 / 24 as the one associated with the intended destination address 90 and identifies router 82 as being capable of reaching the route entry. Shortest paths are then computed between routers 76 and 82 . In this example, a single shortest path ( 76 - 82 ) of distance one (all links are assumed to have unit weight) is returned.
  • the next step identifies area 71 as the area in which the shortest path needs to be extended, and router 82 represents the “origin” in area 71 from which the extension needs to be performed.
  • the path extension carried out in area 71 follows the same set of steps as those carried out when computing shortest paths within area 70 . It starts with a Route Query that identifies the route entry associated with the destination address 90 134 . 34 . 21 . 142 in area 71 . The route query again returns 134 . 34 . 2 .
  • the next step consists of computing a shortest path between routers 82 and 94 through area 71 . This returns one shortest path 82 - 96 - 94 with a distance (in area 71 ) of two. When concatenated with the initial shortest path segment ( 76 - 82 ) computed in area 70 , this returns an extended path segment 76 - 82 - 96 - 94 with a total distance of three. Because destination 90 is still not local to area 71 the path extension process needs to be again repeated for the next area, area 72 . This eventually completes by returning the end-to-end path 76 - 82 - 96 - 94 - 98 - 99 that has a total distance of five.
  • the previous examples were cast in the context of an “instant query”, so that the query processing terminates at that point.
  • the query is a persistent query
  • additional processing is required to track path dynamics through the set of events that the persistent query targets.
  • the RQ module registers with the CIS to be notified of routing updates as the RAG receives them. On receiving any such update the RQ module may query the CIS again, if it perceives that a path change is likely.
  • playback or play-forward persistent queries the processing of the query continues while stepping through the list of routing updates associated with the query.

Abstract

A method and system for extracting and building end-to-end route information in a multi-area Internet protocol (IP) autonomous system (AS) is disclosed. The method and system enable a user, such as a network administrator, to explicitly identify a full set of paths (links and routers) that a given IP packet would potentially traverse from its entry point in the source area of the AS where it originates until its exit point in its intended destination area.

Description

    FIELD OF THE INVENTION
  • The present invention relates generally to a method and system for acquiring information from a packet communications network. More particularly, the present invention relates to a method and system for determining the set of links and routers that are traversed by traffic to and/or from an individual user of a packet communications network.
  • BACKGROUND OF THE INVENTION
  • An Internet protocol (IP) network is a large distributed system in which individual routers automatically adjust their decisions on how to forward packets based on information they learn from their neighbors about the state of the network. This design permits rapid recovery in case of link or router failures by allowing affected routers to re-route packets around the failure as soon as they discover it.
  • However, this distributed mode of operation and the associated robustness it affords come at a price. For example, accuracy in characterizing the behavior of the network at any given time is a complex task. Because of this, many of the network management functions that are available for networks based on more traditional technologies, e.g., connection-oriented such as frame relay or asynchronous transfer mode (ATM), are difficult if not impossible to replicate in IP networks. For example, in a connection-oriented network, the state associated with each connection/user provides the network administrator with a ready handle for tracing its path and monitoring the resources it relies on. In contrast, in IP networks because routing decisions are made in a distributed fashion by many routers that are only concerned with local packet forwarding decisions, there is no single entity with complete knowledge of the entire path that a packet will follow at any given time. Again, this makes it more difficult for a network administrator to precisely identify the path that the traffic between, for example, two customer sites, is following when traversing the network.
  • As a consequence, upon identifying a highly congested link, a network administrator has no or only limited visibility into which customers may be experiencing poor performance as a result of this congestion. Similarly, in the presence of a link failure, identifying which customers are immediately affected as well as predicting which ones may also experience a change in service performance shortly after the failure is again a very complex task in IP networks.
  • Management tools do exist for IP networks, but they are typically reactive or operate at a coarse granularity, i.e., not at the level of the end-to-end performance of an individual customer or site. For example, routers typically support standard Management Information Bases (MIBs) that can be queried using protocols such as the Simple Network Management Protocol (SNMP). MIBs provide detailed state information about individual routers, e.g., interface status, number of packets or bytes transmitted and received on each interface, etc. However, this information is local to each device, and does not offer a network wide perspective. Furthermore, piecing together MIB information from multiple routers to derive end-to-end performance measures of relevance to a given customer is not an easy task. A similar limitation exists when relying on traffic monitoring information that is routinely gathered at routers using mechanisms such as Cisco's NetFlow™ or Juniper cflowd™. These monitoring devices capture detailed information about the traffic crossing a given interface, but again do not have the ability to identify end-to-end paths. Converting such traffic monitoring data into end-to-end intelligence is a laborious task.
  • A few tools exist that are capable of end-to-end sampling of paths traversing an IP network. Most of them are based on two core utilities built into the Internet Protocol, ping and traceroute, which allow a network administrator to probe the network in order to generate estimates of end-to-end performance measures such as packet loss and delay, and record full path information. However, solutions based on utilities such as ping and traceroute often are not desirable because they are neither scalable nor capable of providing real-time information about the network behavior as a user experiences it.
  • Accordingly, it is desirable to provide an improved method and system for monitoring, tracking, and/or predicting the distributed routing state of an IP network.
  • The following is provided as additional background information about the Internet and Internet routing protocols to help the reader understand the context of the present invention:
  • The Internet is a global network that consists of multiple interconnected smaller networks or Autonomous Systems (AS). The delivery of packets across this Interconnection of Networks is carried out under the responsibility of the IP suite. In particular, routing protocols disseminate information that allows distributed decisions to be made on how best to forward packets towards their destination.
  • Internet routing protocols can be divided into intra-domain and inter-domain protocols, with inter-domain protocols communicating information between ASs, while intra-domain protocols are responsible for determining the forwarding of packets within each AS. This general architecture and the associated suite of protocols are rapidly becoming the de facto technology on which modern communication networks are built. This dominance extends from simple local area networks to large-scale, international carrier networks, and is largely due to the robustness and efficiency of networks built using it. In particular, IP networks are often referred to as “connectionless”, and the delivery of data packets to their intended destination is performed through a number of “independent” decisions made by the routers to which a packet is being forwarded.
  • SUMMARY OF THE INVENTION
  • It is therefore a feature and advantage of the present invention to provide an improved method and system for monitoring, tracking, and/or predicting the routing path of one or more packets under an IP protocol.
  • In accordance with one embodiment of the present invention, a method of identifying a path of travel for a packet in a multi-area domain operated according to a link state routing protocol includes the step of receiving topology information from a plurality of individual areas in a domain. It also includes the steps of identifying a plurality of intra-area least cost paths from the topology information, and assembling a subset of the plurality of intra-area least cost paths into an end-to-end path between a starting address and a destination address. Each least cost path preferably comprises a series of routers, with links or networks between routers.
  • Optionally and preferably, in the identifying step, at least one exit point from the first area through which the destination address is reachable is identified, at least one least cost path segment within the first area between the starting address and at least one of the exit points is constructed, and at least one of the least cost path segments is selected to result in at least one selected first area least cost segment. As an additional option, the exit point from first area may be the destination address. The identifying step may also include identifying all exit points from the first area through which the destination address is reachable.
  • The identifying step may also include the step of, for at least one of the exit points associated with at least one of the selected least cost path segments, identifying a second area within the domain to which said at least one exit point is connected. The identifying step may also include the steps of identifying at least one exit point from the second area through which the destination address is reachable, constructing at least one least cost path segment within the second area between the at least one exit point of the first area and at least one exit point of the second area, and selecting at least one of the least cost segments within the second area to result in at least one selected second area least cost segment. Under this option, the assembling step may include connecting one of the selected first area least cost segments and one of the selected second area least cost segments. Also under this option, the exit point of the second area may be the destination address.
  • As a further option to the embodiment described in the previous paragraph, the second constructing and selecting steps may be repeated for one or more additional areas, and the connecting step may include connecting the least cost segments for all areas for which said steps have been performed. Optionally and/or additionally, each constructing step may include constructing all possible least cost path segments, and the assembling step may include connecting a plurality of the least cost path segments between the starting address and the destination address.
  • Any or all of the method elements described above may be embodied in instructions, contained on a computer-readable carrier, that are capable of instructing a computing device to perform the elements.
  • In accordance with an alternate embodiment of the invention, a method of storing historical routing information in a routing domain operating according to a link state routing protocol, includes the steps of storing a plurality of routing events advertised in a routing domain as they are received over time, and identifying a set of time instants for which a complete context of routing and topology information of the routing domain will be maintained. At each time instant identified in the identifying step, at least one time-stamped routing information context is constructed by storing data structures representing current topology and routing states of the routing domain. For each of the time-stamped routing information contexts, a time ordered list of routing events is constructed as the events are received over time until the next time instant identified in the identifying step. Optionally, the routing domain may be a multi-area routing domain, the time-stamped routing information contexts may logically be partitioned through the separate storage of information pertaining to each area in the routing domain, and the constructing step may include constructing a separate time ordered list of routing events for each area in the routing domain.
  • Also optionally, the embodiment described in the previous paragraph may include the step of specifying a starting point in the routing domain, a destination address in the routing domain, a starting time, and an ending time. It may also include the steps of reviewing the time-stamped routing information contexts to identify the context one having a time stamp that is latest yet still precedes contexts with a time-stamp preceding the starting time, and constructing at least one updated time-stamped routing information context by sequentially processing routing events from the time ordered list of routing events associated with the time-stamped routing information context until reaching the last routing event having a time-stamp that that precedes the starting time. It may also include the step of constructing path information between the starting point and the destination address using the updated time-stamped routing information context.
  • In accordance with an alternate embodiment of the invention, a method of identifying a path between a starting address and a destination address in a routing domain operated according to a link state routing protocol includes the steps of specifying an ordered list of routing events, providing a routing information context representing a starting topology and a routing state of a routing domain, constructing path information between a starting address and a destination address using the routing information context, updating the routing information context in accordance with a next routing event in the ordered list of routing events, and repeating the constructing and updating steps above until reaching a last routing event in the ordered list of routing events.
  • There have thus been outlined the more important features of the invention in order that the detailed description thereof that follows may be better understood, and in order that the present contribution to the art may be better appreciated. There are, of course, additional features of the invention that will be described below and which will form the subject matter of the claims appended hereto.
  • In this respect, before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and to the arrangements of the components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein, as well as the abstract, are for the purpose of description and should not be regarded as limiting.
  • As such, those skilled in the art will appreciate that the conception upon which this disclosure is based may readily be utilized as a basis for the designing of other structures, methods, and systems for carrying out the several purposes of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the present invention.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates an exemplary AS, or routing domain, where the present invention may be applied, including various elements of the AS such as areas, routers, route acquisition modules, a route aggregation module, an a route query module.
  • FIG. 2 illustrates exemplary steps that may be performed by a route acquisition module to gather topology information from an individual area in accordance with the present invention.
  • FIG. 3 illustrates the types of information and memory areas that may be allocated by a route aggregation module.
  • FIG. 4 illustrates the address information that may be used in order to identify specific routers, entry points, and/or exit points in an area.
  • FIG. 5 illustrates a preferred data structure of route association data received from multiple areas of an autonomous system in accordance with the present invention.
  • FIG. 6 is an example of an area-level map showing known boundary routers and known border routers for an autonomous system or routing domain.
  • FIG. 7 illustrates an example of a raw advertisements table comprising a collection of information gathered by route acquisition modules.
  • FIG. 8 illustrates a preferred embodiment of a structure of a context access tree that illustrates the format of the data structures used to capture the evolution of the network state over time.
  • FIG. 9 illustrates, in flowchart form, a preferred embodiment of the method of processing a query for a route identification in accordance with the present invention.
  • FIG. 10 illustrates an exemplary routing domain containing a starting point, destination addresses, multiple areas, and multiple routers within each area.
  • DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION
  • A preferred embodiment of the present invention provides an improved method and system for monitoring, tracking, and/or predicting the routing path of one or more packets under an IP protocol.
  • The present invention allows a network administrator, network monitoring system, or other human or automated user to identify the path or paths followed or expected to be followed by any packet traveling though an AS, where the packet has a known entry point or address and a known or anticipated destination address. The destination address is associated with a routing entry, typically from a routing table, and the present invention constructs the path that was or is expected to be followed through the routing domain by the packet associated with the routing entry. Optionally and preferably, when more than one path is possible, the invention is capable of constructing the complete set of possible paths, any of which the packet may follow.
  • FIG. 1 illustrates an exemplary AS, or routing domain, where the present invention may be applied. The domain illustrated in FIG. 1 is not, of course, the only domain configuration in which the invention may apply, but it is only intended to serve as an illustration of one possible domain. Referring to FIG. 1, the illustrated AS includes three areas 10, 11, and 12. The present invention may also be used with an AS having more than three or fewer than three areas. The AS such preferably follows a link state routing protocol such as open shortest path first (OSPF) or ISIS. Each area typically includes a plurality of routers such as 20, 21, and 22 that direct and transport packet traffic between each other within each area, as well as to and from external routers in other areas. These may include: (1) area routers 20 that route information to and from other routers that are associated with a single area; (2) border routers 21 which serve as routers for two or more areas within the AS and provide for the passage of traffic from one area 11 to another area 10 and vice-versa; and (3) boundary routers 22, which serve as exit and/or entry points to and from the AS.
  • In accordance with the present invention, the AS includes one or more Route Acquisition (RAQ) modules 15, 16, and 17. Typically, there is one RAQ module for each area of the AS, although it is possible that an area may have no RAQ module or more than one RAQ module. The RAQ modules, which preferably have the features of a routing device, essentially serve as “stub-routers” and participate in the routing protocol of their respective area. This allows them to receive much or all of the routing information exchanged between routers in their area. In the context of a link state protocol, this information provides detailed background about the internal topology of the area, the set of addresses associated with the different routers in the area and the current state of various network nodes and interfaces. It may also provide summarized information regarding destinations in other areas and outside the AS, or how to reach them.
  • The exact structure and specification of the information received by the RAQ module depends on the routing protocol in use, but a key feature is that it provides information about the “cost” of reaching local destinations inside the area, as well as remote destinations through different “exit” points from the area. The “cost” refers to the distance that a packet must travel to reach a destination from a starting point. The cost may be directly related to a number of “hops” between routers. For example, referring to area 11 in FIG. 1, if the cost of traveling between each router were, for example, one, then the cost for a packet to travel from RAQ module 15 to router 21 via router 20 would be two, since it takes two “hops” to reach the destination: a first hop to router 20 and a second hop to router 21. Alternatively, if the cost of the link between router 21 and router 20 were, for example, three, then the total cost for the packet to travel from RAQ module 15 to router 21 through router 20 would be one plus three, which is four.
  • The AS also includes a Route Aggregation (RAG) module 18. One RAG module is the default configuration, but more than one RAG module is a possible option. The RAG module 18 receives and processes the information obtained by the RAQ modules, and is described in more detail below. The RAG module 18 may be any computing device, such as a PC, laptop, server, or individual work station having a processor and memory.
  • The RAG module 18 is in substantially constant communication with many, and preferably all, of the RAQ modules in the different areas of its AS. The RAG module receives from the RAQ modules the routing information that the RAQ modules have acquired through participating in the routing protocol of their individual area. The RAG module parses and processes this information to support the extraction of end-to-end (across the AS) path information, even across multiple areas. Thus, the RAG module performs a key function, as the routing information from individual routers typically only provides local path information specific to individual areas. The RAG module structures the routing information associated with different areas so as to facilitate its piecing together to create end-to-end paths in response to route queries.
  • The RAG module 18 includes a component referred to herein as the route storage sub-module (or, more briefly, the “storage module”). The storage module maintains information gathered by the RAG from the RAQs, both current and historical. Thus, the storage module is preferably sufficient to store a large quantity of information received from the RAQ modules. However, RAGs with smaller memory amounts can be used. When stored, historical information can be stored in raw (i.e., unprocessed) form or supplemented with one or more indices, tables, and/or summaries to enable rapid retrieval of historical state. This information can be used for both a playback, or path analysis, function and a play-forward, or predictive, function, each of which is described in more detail below.
  • The AS also includes at least one Route Query (RQ) module 25 that serves as an interface for a user, such as a network administrator, to retrieve information collected by the RAG module. The RQ module 25 may be a separate device, such as a computing device having an input/output port or communications port, or it may be co-located with another device. For example, FIG. 1 illustrates the RAG module 18 and the RQ module 25 as being installed on a single computing device. In fact, any or all of the modules described above can be considered functional units, and two or more of them may be co-located in the same physical device.
  • The RQ module 25 interfaces to the RAG module 18 and coordinates the process of retrieving complete path information from the data structures maintained by the storage module. The RQ module 25 accepts as inputs an identifier for the starting point within the AS for a path or route that is to be retrieved, and an identifier for the end point or destination for the path. The identifier of the starting point can be a host name or IP address local to the AS, i.e., belonging to one of the subnets in the AS, or be in the form of an interface number belonging to one of the routers in the AS, i.e., identifying the entry point into the AS. The identifier of the desired end-point or destination will typically be in the form of a host name or IP address, and need not be associated with a device that is local to the AS. In the case of a remote end-point, the path information that is returned extends from the (local) entry point in the AS to the exit point from the AS towards the next AS that is to be used in order to reach the remote destination.
  • Optionally, the RQ module 25 may also accept a time parameter to identify whether the information to be provided is a playback (i.e., analysis of a path previously traveled) or play-forward (i.e., predictive) response. For the play-forward embodiment, the RQ module may also accept additional events pertaining to “what-if” scenarios. The optional time parameter (which typically is coordinated with or relates to a clock associated with the RAG module) would identify the time at which state dynamics are sought to be represented. If the time indicated is in the future, additional events, identified as a sequence of (time, network element, state) may be accepted as input by the RQ.
  • As mentioned above, a RAQ module essentially serves the function of a “stub-router” that participates in the routing protocol of its own area. There will typically be one RAQ per area, although more than one could be deployed for redundancy purposes. In the context of a link state routing protocol, topology (i.e., structure of an area such as router addresses and cost between routers) and route information is flooded through each area, so that each router acquires a complete topological real-time map of its area and of the location of route entries. In addition, in each area, routers connected to other areas or other ASs, i.e., border routers (21 on FIG. 1) and/or boundary routers (22 on FIG. 1) also flood within each of their areas information regarding their ability to reach route entries that lie outside the area. The information may be as simple as stating that they can reach destinations in other areas (as would be the case in a domain following the ISIS protocol), or it may include the identity of the routing entries they have learned, the cost associated with reaching those routes when going through them, and/or other information items (as would be the case in a domain following the OSPF protocol). Routers inside an area use this information to determine how to forward packets along shortest paths towards the route entry that matches the packets' destination address.
  • FIG. 2 illustrates exemplary steps performed by a RAQ module in accordance with the present invention. Referring to FIG. 2, as a result of participation in the flooding process, each RAQ module receives all updates pertaining to changes in routing and topology information (step 30). The RAQ is then responsible for making that information available to the RAG. Specifically, the RAQ receives information transmitted by its neighboring routers within the area and uses that information to build a topology database. Preferably, when updates are received that pertain to a topology element such as a router, a link and its cost, local route entries reachable from each router, and/or (for routers providing connectivity to other areas or routing domains) information regarding the reachability of remote route entries, the RAQ module checks the topology database to determine whether the information is new (step 32). If the information is not new, the RAQ module does nothing with the information (step 34) and watches for additional information (repeating step 32). If the update corresponds to new information, then the RAQ module updates its topology database with the new information (step 36), and it also forwards the updated or new information to the RAG module (step 38). The RAG module maintains a global topology database that contains information received from all RAQ modules in the AS with which it communicates.
  • In addition to changes caused by the receipt of an update from one of the RAQ's neighboring routers, there are other events that can affect the routing and topology information maintained by the RAQ. In particular, most link state routing protocols include various timer based “liveness” mechanisms to detect failures and remove out-of-date information from the topology database. The expiration of one such timer triggers the removal of a corresponding piece of information from the topology database. Such a change also needs to be reported to the RAG to ensure that its information is consistent with that maintained by the RAQ. In other words, the RAQ acting as a router maintains an up-to-date view of routing and topology information in its own area, and is responsible for ensuring that this information is conveyed to the RAG in a timely and reliable manner.
  • The topology database that the RAQ module builds provides it with substantially complete knowledge about routers and links (and their cost) in the RAQ module's own area, as well as possibly route entries reachable within and outside its own area or the identity of routers capable of reaching remote entries.
  • As noted above, the RAQ module is preferably any type of routing device that may be commonly found or used in the AS or in a comparable AS. In accordance with a preferred embodiment of the present invention, the RAQ module is not required to forward transit data. As a result, although it functionally appears as full-fledged router, the particular RAQ module used optionally can be one of relatively low-end technology.
  • Referring back to FIG. 1, the RAG module 18 collects and manages information assembled from the various RAQ modules 15, 16, and 17 into a form that is easily queried by the RQ module 25. There is typically one RAG per AS or routing domain, although a single RAG could be shared across multiple domains, and alternatively multiple RAGs could be used within the same domain for redundancy purposes. For simplicity, the preferred embodiment described herein assumes that there is one RAG serving a given routing domain. The RAG maintains a number of data structures used to store and organize the information it receives from RAQs in different areas.
  • FIG. 3 illustrates the preferred types of information that may be received and memory areas that may be allocated by the RAG module. The RAG 39 maintains at least two sections or types of memory. The information includes two types of contexts. One context corresponds to the current routing domain state, while others are associated with past routing states. The first type, a Contextual Information Structure (CIS) 40, represents a snapshot of the routing state of the network at a particular instant, and can be searched to provide end-to-end (through the routing domain) path information in response to queries placed by the RQ module. The past routing states, together with raw-data received from the RAQs, processed event indices, and other structures pertaining to the past dynamics of the network, make up the historical information that the RAG maintains in the second type of memory, a historical information structure (HIS) 46.
  • The RAG module has two roles. In its downward-facing (or AS-inward) role, it communicates with the RAQs and assembles the updates that it receives from the RAQs. In its upward-facing (or AS-outward) role, the RAG module creates and deletes CISs in response to requests from the RQ module.
  • Each CIS includes at least one, and preferably several, several area data structures (ADS) 42, each with a corresponding route association data (RAD) structure 44. The CIS pieces together information received from different RAQ modules so that the information can be searched to provide end-to-end (through the routing domain or AS) path information in response to queries placed by the RQ module. This piecing together is achieved through a topology map that identifies how the different area data structures are linked together in the AS. Each ADS is essentially a replica of the area's topology database constructed in a manner essentially similar to how routers construct their own area topology database. This is made possible by the fact that the RAQs ensure that any update they receive is communicated to the RAG. In other words, the RAG receives all relevant updates from each area and uses them to reproduce the area topology databases that are separately maintained in each area by the RAQ for the area. Each topology database contains a list of all the routers in the area together with their links and networks, as well as adjacencies, i.e., the set of routers reachable through a given link or network. The information available from an area database allows the computation of shortest paths between any pairs of routers or interfaces in the area.
  • The ability to associate those shortest paths with route entries, and therefore destination addresses, is provided through the RAD structure 44. The RAD 44 is similar to the routing table that is maintained by each router, with the difference that instead of storing the set of next hops associated with the shortest paths computed by the router for each routing entry, the information that is kept is the identity of the router from which the route was learned. A primary function of the RAD is to maintain knowledge of which router a given route entry is associated with. A route entry is said to be associated with a router if the router is one that “advertised” reachability to the route entry.
  • The concept of advertising a route is illustrated in embodiment shown in FIG. 4, which illustrates an expanded version of a single area 50. Referring to FIG. 4, each router is associated with, or “advertises,” a list of routes that are reachable from the router. For example, router 51 advertises both: (1) “area internal” routes, or routes associated with networks directly reachable from the router; and (2) “area external” routes, or, routes associated with networks located in other areas or routing domains. Route entry 48.13.4.0/24, which is advertised by router 51, is an example of an area internal route. Route entry 173.58.0.0/16, also advertised by router 51, is an example of an area external route. Note that association of a router with an area external route does not necessarily require an explicit advertising by the router that it can reach the route entry. It is possible for such an association to be implicit, i.e., the router is known to be associated with area external route entries. The RAD consists of a binary tree structure, such as a Patricia Trie (see FIG. 5) or an Adelson-Velskii-Landis (AVL) binary tree, that is commonly used in routers to allow the searching of route entries and retrieval of the entry that provides the longest prefix match for a given destination address.
  • As with the building of individual area topology databases shown in FIG. 2, the RAD is built as updates are received from the RAQs. Preferably, all the route entries received in an update are inserted in the RAD, although fewer than all may be inserted in alternate embodiments. If the route entry is already present, the router that originated the update through which the route entry was learned, or which in general becomes known as being associated with the route entry, is added to the set of routers with which the route entry is associated. If the route entry is not yet present in the tree, a new entry is created in the tree, and the set of routers with which the route entry is associated is initialized with the corresponding router. In the case of the receipt of updates that correspond to the withdrawal of a route entry, the inverse process is followed, i.e., the tree is searched for the route entries that are to be withdrawn and the router that issued the withdrawal is removed from the list of routers associated with the route entry. In case the router was the only one associated with the route entry, the entry is either deleted or marked as inactive. The inactive marking is useful when it is likely that the route entry will be added again in the near future.
  • FIG. 5 illustrates the structure of a RAD implemented using a Patricia Trie. The structure includes the routing entries that are known for an area, as well as the routers that are known to be associated with (i.e., capable of reaching) each routing entry. Route entries are stored at the leaves of the Trie and include the list of routers associated with them. The nodes of the Trie illustrate exemplary bit positions. For example, FIG. 5 illustrates an example where route entry 173.58.0.0/16 is advertised in the area by both routers 51 and 52 (of FIG. 4), and as a result the identity of the two routers is included in the entry kept for 173.58.0.0/16.
  • The RAG module also keeps a data structure, a topology map that provides information needed to determine how the different areas are connected to each other, and for identifying routers that provide connectivity to outer routing domains. This information is readily obtained by identifying routers that advertise the ability of reaching routes in other areas or outside of the AS. Based on that information, the RAG constructs an “area-level” map of its routing domain, which is a high-level map showing only routers connecting areas or connecting to other routing domains. An example of such a map is shown in FIG. 6.
  • The combination of area-level topology and per area detailed topology maps provides the RAG with complete knowledge for determining the set of (shortest) paths actually followed by packets when crossing the routing domain. In addition to maintaining such knowledge for the current state of the network, the RAG also keeps track of past routing states so as to be able to respond to path queries that pertain to time instants in the past. As mentioned earlier, this information is kept in a portion of memory referred to herein as the RAG Historical Information Structure (HIS).
  • Historical information is useful to support “playback” queries used to identify how paths evolved in response to past changes in the network routing state. The information maintained for this purpose consists of a Raw Advertisements Table (RAT) that includes all updates gathered by the RAG from the RAQs, as well as a Context Access Tree (CAT) that organizes a combination of contexts and updates into a tree structure for easy recovery of past network dynamics. The RAT is a fairly simple structure that keeps a list of events received from various RAQs. It organizes updates based on the time received, the RAQ and area from which the message originated, the network node that originated the advertisement, as well as the raw update itself. An exemplary RAT is illustrated in text form in FIG. 7.
  • In contrast, the CAT is a more complicated structure. An exemplary CAT is illustrated in FIG. 8. As shown in FIG. 8, the CAT comprises a timeline with various nodes 60, 61, 62, and 63, each of which contains a contextual information structure (CIS) such as 66 and 68 corresponding to a snapshot of the network at a point in time. Linked to each component of the CIS (each area data structure and its RAD) is a time-ordered lined-list of events such as 67 and 69, each of which corresponds to an update that caused a change in the state of the component. This hybrid structure, i.e., the combination of raw information and complete routing state as maintained in the CISs at different time-instances, provides an efficient trade-off between minimizing the amount of information that needs to be stored and allowing for the rapid reconstruction of the CIS associated with any given time instant in the past.
  • By storing this information in the HIS, the RAG is able to answer queries that pertain to any given routing state, both present and past. The initiation of queries is performed through the RQ module described below, which is responsible for accessing the different data structures maintained by the RAG.
  • The RQ module is responsible for returning a complete, end-to-end path, or set of such paths, in response to a route query specifying a starting point or origin in the routing domain and a destination address, possibly located outside of the routing domain. The RQ module is capable of answering two different types of route query—instant queries and persistent queries. Instant queries require single-shot responses in the form of a complete, end-to-end path or set of paths. Persistent queries, on the other hand, seek to track the dynamics of a complete, end-to-end path or set of paths over time. There are multiple types of persistent queries based on the conditions under which path dynamics are to be tracked. We distinguish between standard persistent queries, playback persistent queries, and play-forward persistent queries. Additional types of queries are possible, but are not required to practice the present invention.
  • A standard persistent query is similar to an instant query with the one difference that the query is to be persistently reissued each time a routing update is received (at the RAG) that has the potential to affect the path or set of paths that was previously returned. In other words, a standard persistent query tracks the evolution of a path or set of paths over time, as events, e.g., link or router failures, affect the routing state in the routing domain.
  • A playback persistent query specifies a starting time in the past and its goal is to track the evolution of a path or set of paths from that point on over a given period of time. In the context of a playback query it is then possible to step through events that have occurred over a period of time in the past, and for each identify which impact, if any, it had on the path or set of paths that were initially in effect.
  • A play-forward persistent query is similar to a playback query in that it specifies a starting time, possibly in the past, and requires stepping through a set of events in order to identify their impact on the path or set of paths that were initially returned. The main difference between a play-forward query and a playback query is that with a play-forward query, the set of events that are to be used can be specified as part of the query, in order to allow experimenting with different “what if” scenarios and their impact on routing.
  • Because it only needs to be responsible for retrieving path information from the RAG and possibly updating it in response to routing updates, the structure of the RQ module is optionally and preferably much simpler than that of the other modules. The RQ only needs to maintain path structures that have been returned in response to previous queries, although maintenance of other information is possible but not necessary to practice the present invention. Specifically, for each active query session the RQ keeps both (1) the information that was initially provided when the query was first issued, and (2) all subsequent path structures that were returned in response to the query. In the case of an instant query, this consists of only the origin that was specified for the path, the desired destination address, and the path or set of paths that were returned by the RAG. In the case of a persistent query, the RQ needs to also maintain all intermediate path structures that were returned in response to events that affected the original path structure. The set of events that were considered also needs to be kept.
  • The operation of the system described in the preferred embodiment may be described in response to five principal triggers: (1) RAQ initialization, (2) RAG initialization, (3) RQ initialization, (4) Routing update arrival at a RAQ and at the RAG, and (5) Query arrival at the RQ. A description of each event follows:
  • RAQ initialization: The RAQ initialization has two parts. The first is essentially the initialization phase, such as that which may be followed by a typical router in the routing domain. It consists of a device level initialization followed by a set of procedures aimed at ensuring that all routers in a given area of the routing domain have consistent routing information. In the case of a RAQ that acts as a stub router, this will amount to providing its own routing information to its neighboring router(s) and acquiring its (their) routing information. The second part of the RAQ initialization is concerned with the establishment of a communication channel with a RAG and with the initial exchange of routing information with it. The RAQ first retrieves, e.g., from a configuration file, the address of the RAG with which it needs to communicate and proceeds to initialize their communication channel. Once this step has been carried out, and assuming that the first part of the RAQ initialization has completed, i.e., it has acquired stable routing information, the RAQ initiates the transfer of its topology database and associated data structures to the RAG. The RAQ initialization terminates after this next step.
  • RAG initialization: The RAG initialization is also carried out in multiple phases. The first phase consists of device initialization and the creation of global data structures associated with the routing domain for which the RAG is responsible. It also includes the initialization of the procedures needed to enable future communications between the RAG and the different RAQs in the routing domain. For example, this can mean listening on a well-known port number or registering for notification of certain event types. Once this first phase has completed, the RAG is ready to receive information from the RAQs and will go through additional initialization procedures each time it discovers a new RAQ. The initialization procedures associated with the discovery of a new RAQ include the creation of the corresponding area data structures described in the description of the RAG above. In other words, the RAG creates a new area structure and also updates its routing domain level structure to reflect the existence of the new area. Information regarding the area's internal topology and overall connectivity in the routing domain is then added as it is received from the RAQ. This second phase completes after the RAQ finishes communicating its initial routing and topology information to the RAG.
  • RQ initialization: The RQ initialization procedures are optionally and preferably relatively minimal. Preferably, they include little more than contacting the RAG(s) associated with the routing domains the RQ is serving and retrieving from them relevant information that needs to be made available through the RQ User Interface. The identification of the relevant RAG(s) is typically provided through local configuration.
  • Routing Update: Routing (and topology) updates are transmitted by the RAQs to the RAG and are responsible for ensuring that the RAG maintains accurate information regarding the routing state of its routing domain. A RAQ determines that it needs to forward a routing update to the RAG whenever it itself receives an update (internal or external) that results in the modification of its own topology database. The resulting change must then be communicated to the RAG, which triggers the generation of a routing update by the RAQ. Upon receipt of the routing update, the RAG first identifies the area with which it is associated. This information is available through association with the identity of the RAQ that transmitted the update. Once the relevant area has been identified, the RAG accesses the corresponding CIS and proceeds to modify it in order to reflect the changes advertised in the routing update.
  • The nature of the changes required depends on the nature of the routing update. For example, the changes may range from the modification of an existing data structure or field, to the deletion of an existing data structure, to the creation of a new data structure. For example, a routing update that advertises a new cost for a link will result in the corresponding value being modified in the ADS. A routing update associated with the deletion or failure of a link or a router will result in the removal of the corresponding data structures of fields in the ADS. Conversely, a routing update associated with the introduction of a new link or a router will result in the creation of data structures necessary to represent those new entities in the ADS. Furthermore, in both cases, the RAD will also be correspondingly modified. In the case of a link or interface failure, it may be necessary to remove the attached router from the list of routers through which any associated route entry is reachable. For example, a router that loses connectivity to a given subnet must be removed from the list of routers associated with the route entry corresponding to the subnet, and if the router was the last one in the list, the route entry needs to be marked as unreachable or deleted. The case of a router failure is similar even if it typically requires more changes.
  • In addition to triggering potential modifications to the current CIS maintained by the RAG, the receipt of a routing update also affects the HIS at the RAG. Specifically, any received routing update should be added to one of the link lists of events maintained for the last CIS stored in the CAT, as well as to the RAT that keeps track of all the routing events received by the RAG. Finally, the receipt of a routing event can also trigger the storage of a new CIS in the CAT. Specifically, CISs may be stored in the CAT at regular time intervals, or after a given number of routing updates have been received, or according to some combination of those two criteria. In particular, imposing an upper bound on the number of routing updates that can be linked to a given CIS stored in the CAT is desirable to ensure that the CIS associated with an arbitrary time instant can be reconstructed within a reasonable amount of event processing.
  • Query Processing: The operation of the RQ module on the arrival of a query can be decomposed into a query initialization phase followed by a set of area specific steps and cross-area steps and is described in FIG. 9 in a flowchart format. The query initialization phase includes the following steps: Step 100: The system Determine if the appropriate CIS exists for handling the query. Step 102: If the appropriate CIS does not exist, the RAG creates it. Step 104: The RQ module identifies the source area associated with the starting point or origin of the path. Step 106: The RQ module identifies the origin router associated with the starting or entry point of the path in the source area. Optionally, more than one entry point may be considered.
  • Steps 100 and 102 come into play in the context of playback or play-forward queries that may not start from the current CIS, but which require the extraction of a CIS corresponding to the time instant from which the playback or play-forward scenario is to start. Specifically, when a query pertains to a time instant different from the current time, it is necessary to first recreate the routing state of the routing domain at that time instant. Thus, step 102 is accomplished by retrieving the necessary information from the HIS maintained at the RAG. The first step in this process consists of searching the CAT to identify the CIS with the latest time preceding the time instant from which the query is to start. In other words, the CAT is searched until a CIS is found that represents the full state of the routing domain at the latest time instant prior to the query starting time. Once the corresponding CIS has been identified, the list of routing events attached to the CIS is processed until all events anterior to the query starting time have been accounted for. The resulting CIS describes the routing state of the routing domain, as it existed at the specified starting time of the query. For example, when referring to FIG. 8 and assuming a desired query starting time of 03:40:00 on Sep. 26, 2001, the search of the CAT would terminate at the CIS that was stored at 03:33:36.45 on Sep. 26, 2001, as it corresponds to the last CIS stored prior to 03:40:00 on that day. However, this CIS does not represent the correct routing state at the desired query starting time. In order to recreate the CIS in effect at 03:40:00 on Sep. 26, 2001, it is necessary to process all the routing update events that are attached to the CIS stored at 03:33:36.45 on Sep. 26, 2001 and that were received prior to 03:40:00.
  • Once the appropriate CIS has been retrieved, the next two steps of the initialization performed when a new route query is received are best illustrated by referring to both FIG. 9 and FIG. 10. For this configuration, step 104 of FIG. 9 returns Area 70 of FIG. 10 as the source area for the specified origin point “S” 74, while step 106 of FIG. 9 identifies router 76 (of FIG. 10) as the starting point for paths that are to be returned in response to the route query.
  • Once the query initialization steps have been performed, referring again to FIG. 9, an area-specific set of steps is initiated and proceeds as follows: Step 108: Optionally and preferably, the shortest path segment from the entry point or points will be initialized to a null value. Step 110: Identify the route entry associated with the specified destination address. Step 112: Identify the exit points in the area that are associated with (i.e., that can reach) the route entry. Step 114: Compute shortest paths between the entry point or points and all exit points identified in step 112. If multiple shortest paths are available, preferably all such shortest paths are identified in this step. If multiple shortest paths have been identified, then the system selects those that are viable for reaching the destination address (step 116).
  • If previous paths have been calculated (such as those which may exist in other areas), then the system combines those with the paths determined in step 116 (step 118) and identifies the combinations that terminate in the current area and/or are associated with area local exit points (step 120). The system then returns the paths that are complete (step 122) and checks to see if there are other paths (i.e., other areas) that need to be checked (step 124). In cases where the destination address lies either in another area or in another routing domain, additional areas may have to be traversed before a complete set of paths is returned. If there are no other areas, then the path or paths have been identified and the process ends (step 130), typically by returning a report of the shortest path or paths. If another area or areas need to be checked, the system identifies the next area or areas (step 126), identifies the entry point for each such area (step 128), and repeats the process from step 110.
  • The purpose of steps 110, 112, 114 and 116 is to compute, within a particular area, shortest paths between the specified origin point and all the routers through which the destination could ultimately be reached. Note that when the destination address is associated with a route entry directly reachable from one or more of the routers in the source area, the route query typically terminates at this point. Specifically, when the destination address is associated with an “area-local” route entry, i.e., a route entry associated with a network directly attached to one or more of the area routers, then the RQ determines that all shortest paths between the specified origin and the destination address lie within the area. An exemplary identification of shortest paths within an area can be found in FIG. 10. For example, referring to FIG. 10, if the specified destination address is D1, i.e., 133.40.15.7. In this case, step 114 of FIG. 9 above would return two shortest paths, namely, S-R4-R5-D1 and S-R4-R6-D1. Since address D1 is “local”, i.e., both R5 and R6 are connected to subnet 133.40.15.0/24, the query process would stop there and those two paths would be returned.
  • Referring again to FIG. 10, consider in turn destination address 90 (134.34.21.142) that is associated with a local route entry in area 72, i.e., a different area than that of the origin of the route query (area 70). The Route Query process starts by returning route entry 134.34.21.0/24 as the one associated with the intended destination address 90 and identifies router 82 as being capable of reaching the route entry. Shortest paths are then computed between routers 76 and 82. In this example, a single shortest path (76-82) of distance one (all links are assumed to have unit weight) is returned.
  • Because destination 90 is not local to area 70, the shortest path 76-82 needs to be extended out of area 70. Note that since it is the only possible shortest path, there is no need to identify which shortest path is to be extended. The next step identifies area 71 as the area in which the shortest path needs to be extended, and router 82 represents the “origin” in area 71 from which the extension needs to be performed. The path extension carried out in area 71 follows the same set of steps as those carried out when computing shortest paths within area 70. It starts with a Route Query that identifies the route entry associated with the destination address 90 134.34.21.142 in area 71. The route query again returns 134.34.2.0/24 and identifies router 94 as being able to reach the destination. The next step consists of computing a shortest path between routers 82 and 94 through area 71. This returns one shortest path 82-96-94 with a distance (in area 71) of two. When concatenated with the initial shortest path segment (76-82) computed in area 70, this returns an extended path segment 76-82-96-94 with a total distance of three. Because destination 90 is still not local to area 71 the path extension process needs to be again repeated for the next area, area 72. This eventually completes by returning the end-to-end path 76-82-96-94-98-99 that has a total distance of five.
  • Note that the above example only illustrates the general steps of the path computation process as it proceeds through multiple areas, and is not meant as a comprehensive description of all possible scenarios. Configurations involving multiple shortest paths within an area and/or multiple possible exit points from an area will give rise to slightly different intermediate steps that can be identified in reference to FIG. 9.
  • The previous examples were cast in the context of an “instant query”, so that the query processing terminates at that point. On the other hand, if the query is a persistent query, additional processing is required to track path dynamics through the set of events that the persistent query targets. In the case of a standard persistent query, the RQ module registers with the CIS to be notified of routing updates as the RAG receives them. On receiving any such update the RQ module may query the CIS again, if it perceives that a path change is likely. In the case of playback or play-forward persistent queries, the processing of the query continues while stepping through the list of routing updates associated with the query.
  • The many features and advantages of the invention are apparent from the detailed specification. Thus, the appended claims are intended to cover all such features and advantages of the invention which fall within the true spirits and scope of the invention. Further, since numerous modifications and variations will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation illustrated and described. Accordingly, all suitable modifications and equivalents may be included within the scope of the invention.

Claims (16)

1. A method of identifying a path of travel for a packet in a multi-area domain operated according to a link state routing protocol, comprising the steps of:
receiving topology information from a plurality of individual areas in a domain;
identifying a plurality of intra-area least cost paths from the topology information; and
assembling a subset of the plurality of intra-area least cost paths into an end-to-end path between a starting address and a destination address.
2. The method of claim 1 wherein each least cost path comprises a series of routers and links or networks between routers.
3. The method of claim 1 wherein the identifying step comprises:
identifying at least one exit point from a first area through which the destination address is reachable;
constructing at least one least cost path segment within the first area between the starting address and at least one of the exit points; and
selecting at least one of the least cost path segments to result in at least one selected first area least cost segment.
4. The method of claim 3 wherein the exit point from the first area is the destination address.
5. The method of claim 3 wherein the identifying step further comprises:
for at least one of the exit points associated with at least one of the selected least cost path segments, identifying a second area within the domain to which said at least one exit point is connected;
identifying at least one exit point from the second area through which the destination address is reachable;
constructing at least one least cost path segment within the second area between the at least one exit point of the first area and at least one exit point of the second area; and
selecting at least one of the least cost segments within the second area to result in at least one selected second area least cost segment;
and wherein the assembling step comprises connecting one of the selected first area least cost segments and one of the selected second area least cost segments.
6. The method of claim 5 wherein the exit point of the second area is the destination address.
7. The method of claim 5 wherein the second constructing and selecting steps are repeated for one or more additional areas, and wherein the assembling step comprises connecting the least cost segments for all areas for which said steps have been performed.
8. The method of claim 3 wherein the identifying step further comprises identifying all exit points from the first area through which the destination address is reachable.
9. The method of claim 5 wherein
each constructing step comprises constructing all possible least cost path segments; and
the assembling step comprises connecting a plurality of the least cost path segments between the starting address and the destination address.
10. A computer-readable carrier containing instructions thereon that are capable of instructing a computing device to perform the steps of:
receiving topology information from a plurality of individual areas in a multi-area routing domain;
identifying a plurality of intra-area least cost paths from the stored topology information; and
assembling a subset of the plurality of intra-area least cost paths into an end-to-end path between a starting address and a destination address.
11. The carrier of claim 10 wherein each least cost path comprises a series of routers and links or networks between routers.
12. The carrier of claim 10 wherein the instructions relating to the identifying step comprise instructions that instruct the computing device to:
identify at least one exit point from a first area through which the destination address is reachable;
construct at least one least cost path segment within the first area between the starting address and at least one of the exit points; and
select at least one of the least cost path segments to result in at least one selected first area least cost segment.
13. The carrier of claim 12 wherein:
the instructions relating to the identifying step further comprise instructions that instruct the computing device to:
for at least one of the exit points associated with at least one of the selected least cost path segments, identify a second area within the routing domain to which said at least one exit point is connected;
identify at least one exit point from the second area through which the destination address is reachable;
construct at least one least cost path segment within the second area between at least one of the exit points of the first area and at least one of the exit points of the second area; and
select at least one of the least cost segments within the second area to result in at least one selected second area least cost segment; and
the instructions relating to the assembling step comprise instructions to connect one of selected first area least cost segments and one of the second area least cost segments.
14. The carrier of claim 13 wherein the instructions further comprise instructing the computing device to repeat the second constructing and selecting steps for at least one additional area. and wherein the instructions relating to the assembling step instruct the computing device to connect the least cost segments for all areas for which said steps have been performed.
15. A method of storing historical routing information in a routing domain operating according to a link state routing protocol, comprising the steps of:
storing a plurality of routing events advertised in a routing domain as they are received over time;
identifying a set of time instants for which a complete context of routing and topology information of the routing domain will be maintained;
at each time instant identified in the identifying step, constructing at least one time-stamped routing information context by storing data structures representing current topology and routing state of the routing domain; and
for each of the time-stamped routing information contexts, constructing a time ordered list of routing events as the events are received over time until the next time instant identified in the identifying step.
16. The method of claim 15, wherein the routing domain comprises a multi-area routing domain, the time-stamped routing information contexts are logically partitioned through the separate storage of information pertaining to each area in the routing domain, and where the constructing step comprises constructing a separate time ordered list of routing events for each area in the routing domain.
US12/423,392 2000-04-17 2009-04-14 Method and system for path identification in packet networks Expired - Lifetime US8218447B2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/423,392 US8218447B2 (en) 2001-11-29 2009-04-14 Method and system for path identification in packet networks
US12/853,467 US8510468B2 (en) 2000-04-17 2010-08-10 Route aware network link acceleration
US13/964,447 US20140143442A1 (en) 2000-04-17 2013-08-12 Route aware network link acceleration

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/997,420 US6836465B2 (en) 2001-11-29 2001-11-29 Method and system for path identification in packet networks
US10/895,156 US7525920B2 (en) 2001-11-29 2004-07-20 Method and system for path identification in packet networks
US12/423,392 US8218447B2 (en) 2001-11-29 2009-04-14 Method and system for path identification in packet networks

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US10/895,156 Continuation US7525920B2 (en) 2000-04-17 2004-07-20 Method and system for path identification in packet networks

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US11/346,767 Continuation-In-Part US7975066B2 (en) 2000-04-17 2006-02-03 System and method for implementing application functionality within a network infrastructure
US12/853,467 Continuation-In-Part US8510468B2 (en) 2000-04-17 2010-08-10 Route aware network link acceleration

Publications (2)

Publication Number Publication Date
US20090196184A1 true US20090196184A1 (en) 2009-08-06
US8218447B2 US8218447B2 (en) 2012-07-10

Family

ID=25544000

Family Applications (3)

Application Number Title Priority Date Filing Date
US09/997,420 Expired - Lifetime US6836465B2 (en) 2000-04-17 2001-11-29 Method and system for path identification in packet networks
US10/895,156 Active 2025-01-07 US7525920B2 (en) 2000-04-17 2004-07-20 Method and system for path identification in packet networks
US12/423,392 Expired - Lifetime US8218447B2 (en) 2000-04-17 2009-04-14 Method and system for path identification in packet networks

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US09/997,420 Expired - Lifetime US6836465B2 (en) 2000-04-17 2001-11-29 Method and system for path identification in packet networks
US10/895,156 Active 2025-01-07 US7525920B2 (en) 2000-04-17 2004-07-20 Method and system for path identification in packet networks

Country Status (5)

Country Link
US (3) US6836465B2 (en)
EP (1) EP1461883A4 (en)
JP (1) JP2005512393A (en)
AU (1) AU2002352874A1 (en)
WO (1) WO2003049341A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080310377A1 (en) * 2007-06-15 2008-12-18 George Flammer Method and system for providing routing protocols in a frequency hopping spread spectrum network
US20080310311A1 (en) * 2007-06-15 2008-12-18 George Flammer Method and system for providing network and routing protocols for utility services
US20090003214A1 (en) * 2007-06-15 2009-01-01 Silver Spring Networks, Inc. Load management in wireless mesh communications networks
US20090034418A1 (en) * 2007-08-01 2009-02-05 Flammer Iii George Method and system of routing in a utility smart-grid network
US20090168645A1 (en) * 2006-03-22 2009-07-02 Tester Walter S Automated Network Congestion and Trouble Locator and Corrector
US20090228604A1 (en) * 2008-03-05 2009-09-10 Fujitsu Limited Apparatus and method for calculating communication paths
US20110282996A1 (en) * 2009-11-19 2011-11-17 Yoram Zahavi Method and system for dynamically allocating services for subscribers data traffic
US11050821B2 (en) 2017-01-31 2021-06-29 Nchain Licensing Ag Computer-implemented system and method for updating a network's knowledge of the network's topology
US11201809B1 (en) * 2013-02-11 2021-12-14 Riverbed Technology, Inc. Network topology generation using traceroute data
US11706078B1 (en) * 2021-03-22 2023-07-18 Two Six Labs, LLC Internet disruption detection
US11778021B2 (en) 2017-01-31 2023-10-03 Nchain Licensing Ag Computer-implemented system and method for updating a network's knowledge of the network's topology

Families Citing this family (113)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8510468B2 (en) 2000-04-17 2013-08-13 Ciradence Corporation Route aware network link acceleration
US20030101279A1 (en) * 2001-11-29 2003-05-29 Rajiv Maheshwari Method for transferring messages along optimally redundant network paths in a distributed communication network
US20030120769A1 (en) * 2001-12-07 2003-06-26 Mccollom William Girard Method and system for determining autonomous system transit volumes
US7096251B2 (en) * 2002-01-23 2006-08-22 Sun Microsystems, Inc. Calculation of layered routes in a distributed manner
US9026674B1 (en) * 2010-03-22 2015-05-05 Satish K Kanna System and method for accurately displaying communications traffic information
US8310935B1 (en) * 2002-06-20 2012-11-13 Signafor, Inc. Communications failure recovery in data packet networks based on fast determination of alternate routes
EP1387527A1 (en) * 2002-07-30 2004-02-04 Agilent Technologies Inc. Identifying network routers and paths
US7382731B1 (en) * 2003-03-05 2008-06-03 Cisco Technology, Inc. Method and apparatus for updating probabilistic network routing information
US9137033B2 (en) 2003-03-18 2015-09-15 Dynamic Network Services, Inc. Methods and systems for monitoring network routing
US7768946B2 (en) * 2003-04-07 2010-08-03 Nokia Corporation Resource determination in IP-based networks
DE10341336A1 (en) * 2003-09-08 2005-04-07 Siemens Ag Method for optimized deactivation of inter-domain routes
US7472314B2 (en) * 2003-09-26 2008-12-30 Alcatel - Lucent Usa Inc. System and method for monitoring link delays and faults in an IP network
US7509373B2 (en) * 2003-11-24 2009-03-24 At&T Intellectual Property I, L.P. Methods for providing communications services
US7519657B2 (en) * 2003-11-24 2009-04-14 At&T Intellectual Property L, L.P. Methods for providing communications services
US7464179B2 (en) 2003-11-24 2008-12-09 At&T Intellectual Property I, L.P. Methods, systems, and products for providing communications services amongst multiple providers
US7467219B2 (en) 2003-11-24 2008-12-16 At&T Intellectual Property I, L.P. Methods for providing communications services
US7590072B2 (en) * 2004-03-12 2009-09-15 Alcatel Lucent Interworking network maps of network management and element management systems
US8670315B1 (en) * 2004-12-15 2014-03-11 Rockstar Consortium Us Lp Method and apparatus for estimating end-to-end packet delay
US8320255B2 (en) * 2005-02-02 2012-11-27 Cisco Technology, Inc. Inter-domain path computation technique
US7385988B2 (en) * 2005-02-28 2008-06-10 Cisco Technology, Inc. Method and apparatus for limiting VPNv4 prefixes per VPN in an inter-autonomous system environment
US20060222018A1 (en) * 2005-03-30 2006-10-05 Lucent Technologies Inc. Method and apparatus for determining delays of links between switches
US7532631B2 (en) * 2005-04-13 2009-05-12 Cisco Technology, Inc. Method and apparatus for accelerating border gateway protocol convergence
US8072901B1 (en) * 2005-05-09 2011-12-06 Cisco Technology, Inc. Technique for efficient probing to verify policy conformance
US7760738B1 (en) * 2005-07-28 2010-07-20 Verizon Services Corp. Admission control for services
US7983158B2 (en) * 2005-11-30 2011-07-19 Motorola Solutions, Inc. Routing topology bandwidth management methods and system
US7668173B2 (en) * 2005-12-01 2010-02-23 Azalea Networks Method and system for an adaptive wireless routing protocol in a mesh network
US20070258447A1 (en) * 2006-05-04 2007-11-08 Robert Raszuk Inter-area summarization of edge-device addresses using RFC3107
US8289965B2 (en) 2006-10-19 2012-10-16 Embarq Holdings Company, Llc System and method for establishing a communications session with an end-user based on the state of a network connection
US7948909B2 (en) * 2006-06-30 2011-05-24 Embarq Holdings Company, Llc System and method for resetting counters counting network performance information at network communications devices on a packet network
US8488447B2 (en) * 2006-06-30 2013-07-16 Centurylink Intellectual Property Llc System and method for adjusting code speed in a transmission path during call set-up due to reduced transmission performance
US8000318B2 (en) * 2006-06-30 2011-08-16 Embarq Holdings Company, Llc System and method for call routing based on transmission performance of a packet network
US8717911B2 (en) * 2006-06-30 2014-05-06 Centurylink Intellectual Property Llc System and method for collecting network performance information
US8194643B2 (en) * 2006-10-19 2012-06-05 Embarq Holdings Company, Llc System and method for monitoring the connection of an end-user to a remote network
US8184549B2 (en) 2006-06-30 2012-05-22 Embarq Holdings Company, LLP System and method for selecting network egress
US20080002711A1 (en) * 2006-06-30 2008-01-03 Bugenhagen Michael K System and method for access state based service options
US9094257B2 (en) 2006-06-30 2015-07-28 Centurylink Intellectual Property Llc System and method for selecting a content delivery network
US8224255B2 (en) * 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for managing radio frequency windows
US8107366B2 (en) 2006-08-22 2012-01-31 Embarq Holdings Company, LP System and method for using centralized network performance tables to manage network communications
US8576722B2 (en) 2006-08-22 2013-11-05 Centurylink Intellectual Property Llc System and method for modifying connectivity fault management packets
US8223654B2 (en) * 2006-08-22 2012-07-17 Embarq Holdings Company, Llc Application-specific integrated circuit for monitoring and optimizing interlayer network performance
US8537695B2 (en) 2006-08-22 2013-09-17 Centurylink Intellectual Property Llc System and method for establishing a call being received by a trunk on a packet network
US8144586B2 (en) * 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for controlling network bandwidth with a connection admission control engine
US8223655B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for provisioning resources of a packet network based on collected network performance information
US8125897B2 (en) * 2006-08-22 2012-02-28 Embarq Holdings Company Lp System and method for monitoring and optimizing network performance with user datagram protocol network performance information packets
US8743703B2 (en) * 2006-08-22 2014-06-03 Centurylink Intellectual Property Llc System and method for tracking application resource usage
US8549405B2 (en) * 2006-08-22 2013-10-01 Centurylink Intellectual Property Llc System and method for displaying a graphical representation of a network to identify nodes and node segments on the network that are not operating normally
US8619600B2 (en) 2006-08-22 2013-12-31 Centurylink Intellectual Property Llc System and method for establishing calls over a call path having best path metrics
US8228791B2 (en) * 2006-08-22 2012-07-24 Embarq Holdings Company, Llc System and method for routing communications between packet networks based on intercarrier agreements
US8130793B2 (en) * 2006-08-22 2012-03-06 Embarq Holdings Company, Llc System and method for enabling reciprocal billing for different types of communications over a packet network
US8750158B2 (en) 2006-08-22 2014-06-10 Centurylink Intellectual Property Llc System and method for differentiated billing
US7940735B2 (en) * 2006-08-22 2011-05-10 Embarq Holdings Company, Llc System and method for selecting an access point
US20080049639A1 (en) * 2006-08-22 2008-02-28 Wiley William L System and method for managing a service level agreement
US8098579B2 (en) * 2006-08-22 2012-01-17 Embarq Holdings Company, LP System and method for adjusting the window size of a TCP packet through remote network elements
US8531954B2 (en) 2006-08-22 2013-09-10 Centurylink Intellectual Property Llc System and method for handling reservation requests with a connection admission control engine
US8144587B2 (en) 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for load balancing network resources using a connection admission control engine
US8040811B2 (en) * 2006-08-22 2011-10-18 Embarq Holdings Company, Llc System and method for collecting and managing network performance information
US9479341B2 (en) * 2006-08-22 2016-10-25 Centurylink Intellectual Property Llc System and method for initiating diagnostics on a packet network node
US7684332B2 (en) * 2006-08-22 2010-03-23 Embarq Holdings Company, Llc System and method for adjusting the window size of a TCP packet through network elements
US8407765B2 (en) 2006-08-22 2013-03-26 Centurylink Intellectual Property Llc System and method for restricting access to network performance information tables
US8274905B2 (en) * 2006-08-22 2012-09-25 Embarq Holdings Company, Llc System and method for displaying a graph representative of network performance over a time period
US20080052206A1 (en) * 2006-08-22 2008-02-28 Edwards Stephen K System and method for billing users for communicating over a communications network
US8189468B2 (en) 2006-10-25 2012-05-29 Embarq Holdings, Company, LLC System and method for regulating messages between networks
US7808918B2 (en) 2006-08-22 2010-10-05 Embarq Holdings Company, Llc System and method for dynamically shaping network traffic
US8064391B2 (en) 2006-08-22 2011-11-22 Embarq Holdings Company, Llc System and method for monitoring and optimizing network performance to a wireless device
US7843831B2 (en) 2006-08-22 2010-11-30 Embarq Holdings Company Llc System and method for routing data on a packet network
US20080049629A1 (en) * 2006-08-22 2008-02-28 Morrill Robert J System and method for monitoring data link layer devices and optimizing interlayer network performance
US8238253B2 (en) * 2006-08-22 2012-08-07 Embarq Holdings Company, Llc System and method for monitoring interlayer devices and optimizing network performance
US8015294B2 (en) 2006-08-22 2011-09-06 Embarq Holdings Company, LP Pin-hole firewall for communicating data packets on a packet network
US7889660B2 (en) * 2006-08-22 2011-02-15 Embarq Holdings Company, Llc System and method for synchronizing counters on an asynchronous packet communications network
US8307065B2 (en) 2006-08-22 2012-11-06 Centurylink Intellectual Property Llc System and method for remotely controlling network operators
US8199653B2 (en) * 2006-08-22 2012-06-12 Embarq Holdings Company, Llc System and method for communicating network performance information over a packet network
US8194555B2 (en) * 2006-08-22 2012-06-05 Embarq Holdings Company, Llc System and method for using distributed network performance information tables to manage network communications
JP2008187359A (en) * 2007-01-29 2008-08-14 Kyocera Corp Data transmission method, data transmission management system, and data transmission path management device
US7796537B2 (en) * 2007-04-17 2010-09-14 Cisco Technology, Inc. Creating non-transit nodes in a link network
US8111692B2 (en) * 2007-05-31 2012-02-07 Embarq Holdings Company Llc System and method for modifying network traffic
CA2687882A1 (en) * 2007-06-01 2008-12-04 Nortel Networks Limited Distributed connection establishment and restoration
US7733798B2 (en) * 2007-08-28 2010-06-08 Cisco Technology, Inc. Evaluation of network data aggregation
WO2009044455A1 (en) * 2007-10-02 2009-04-09 Fujitsu Limited Routing control apparatus and routing control method
US8756340B2 (en) * 2007-12-20 2014-06-17 Yahoo! Inc. DNS wildcard beaconing to determine client location and resolver load for global traffic load balancing
US7962631B2 (en) * 2007-12-21 2011-06-14 Yahoo! Inc. Method for determining network proximity for global traffic load balancing using passive TCP performance instrumentation
JP4579995B2 (en) * 2008-01-28 2010-11-10 日本電信電話株式会社 Route identification system
US7940668B2 (en) * 2008-03-21 2011-05-10 Cisco Technology, Inc. Method and apparatus to enable an IPe domain through EIGRP
WO2009118050A1 (en) * 2008-03-28 2009-10-01 Telefonaktiebolaget Lm Ericsson (Publ) End-to-end inter-domain routing
US20090245114A1 (en) * 2008-04-01 2009-10-01 Jayanth Vijayaraghavan Methods for collecting and analyzing network performance data
US8068425B2 (en) 2008-04-09 2011-11-29 Embarq Holdings Company, Llc System and method for using network performance information to determine improved measures of path states
JP4988674B2 (en) * 2008-09-08 2012-08-01 株式会社日立製作所 Network monitoring device, network monitoring method, and network monitoring program
EP2353256A1 (en) * 2008-09-29 2011-08-10 France Telecom Determination and management of virtual networks
US7978612B2 (en) * 2008-10-13 2011-07-12 Cisco Technology, Inc. Two-hop relay for reducing distance vector routing information
JP2009060673A (en) * 2008-12-15 2009-03-19 Nippon Telegr & Teleph Corp <Ntt> Route calculation system, route calculation method, and communication node
US8385231B2 (en) * 2009-07-30 2013-02-26 Roberto Rojas-Cessa Disseminating link state information to nodes of a network
US9065745B2 (en) * 2011-10-06 2015-06-23 International Business Machines Corporation Network traffic distribution
US8850065B2 (en) * 2012-01-04 2014-09-30 Alcatel Lucent Diameter route learning
US8831019B2 (en) 2012-05-18 2014-09-09 Renesys Path reconstruction and interconnection modeling (PRIM)
US9143435B1 (en) * 2012-10-19 2015-09-22 Symantec Corporation Management of paths of switches of distributed computing systems
CN103023781B (en) * 2012-12-13 2015-06-10 清华大学 Shortest path tree and spanning tree combined energy-saving routing method
US10404582B1 (en) 2012-12-27 2019-09-03 Sitting Man, Llc Routing methods, systems, and computer program products using an outside-scope indentifier
US10587505B1 (en) 2012-12-27 2020-03-10 Sitting Man, Llc Routing methods, systems, and computer program products
US10411998B1 (en) 2012-12-27 2019-09-10 Sitting Man, Llc Node scope-specific outside-scope identifier-equipped routing methods, systems, and computer program products
US10447575B1 (en) 2012-12-27 2019-10-15 Sitting Man, Llc Routing methods, systems, and computer program products
US10419334B1 (en) 2012-12-27 2019-09-17 Sitting Man, Llc Internet protocol routing methods, systems, and computer program products
US10397101B1 (en) 2012-12-27 2019-08-27 Sitting Man, Llc Routing methods, systems, and computer program products for mapping identifiers
US10404583B1 (en) 2012-12-27 2019-09-03 Sitting Man, Llc Routing methods, systems, and computer program products using multiple outside-scope identifiers
US10212076B1 (en) 2012-12-27 2019-02-19 Sitting Man, Llc Routing methods, systems, and computer program products for mapping a node-scope specific identifier
US10904144B2 (en) 2012-12-27 2021-01-26 Sitting Man, Llc Methods, systems, and computer program products for associating a name with a network path
US10411997B1 (en) 2012-12-27 2019-09-10 Sitting Man, Llc Routing methods, systems, and computer program products for using a region scoped node identifier
US10419335B1 (en) 2012-12-27 2019-09-17 Sitting Man, Llc Region scope-specific outside-scope indentifier-equipped routing methods, systems, and computer program products
US10397100B1 (en) 2012-12-27 2019-08-27 Sitting Man, Llc Routing methods, systems, and computer program products using a region scoped outside-scope identifier
EP3108623B1 (en) * 2014-02-17 2019-04-10 Telefonaktiebolaget LM Ericsson (publ) A method and apparatus for allocating physical resources to a summarized resource
CN104683239B (en) * 2015-03-09 2017-11-03 东北大学 A kind of energy-saving QoS method for routing of Internet
US10771482B1 (en) * 2017-11-14 2020-09-08 Ca, Inc. Systems and methods for detecting geolocation-aware malware
US11301568B1 (en) * 2018-04-05 2022-04-12 Veritas Technologies Llc Systems and methods for computing a risk score for stored information
US10816599B2 (en) 2019-01-16 2020-10-27 International Business Machines Corporation Dynamically power noise adaptive automatic test pattern generation
US10826750B2 (en) 2019-01-31 2020-11-03 Hewlett Packard Enterprise Development Lp Patricia trie for simple network management protocol management information base operations

Citations (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4939726A (en) * 1989-07-18 1990-07-03 Metricom, Inc. Method for routing packets in a packet communication network
US5101348A (en) * 1988-06-23 1992-03-31 International Business Machines Corporation Method of reducing the amount of information included in topology database update messages in a data communications network
US5115433A (en) * 1989-07-18 1992-05-19 Metricom, Inc. Method and system for routing packets in a packet communication network
US5309433A (en) * 1992-06-18 1994-05-03 International Business Machines Corp. Methods and apparatus for routing packets in packet transmission networks
US5317566A (en) * 1993-08-18 1994-05-31 Ascom Timeplex Trading Ag Least cost route selection in distributed digital communication networks
US5323394A (en) * 1992-04-07 1994-06-21 Digital Equipment Corporation Selecting optimal routes in source routing bridging without exponential flooding of explorer packets
US5365523A (en) * 1992-11-16 1994-11-15 International Business Machines Corporation Forming and maintaining access groups at the lan/wan interface
US5398012A (en) * 1992-11-24 1995-03-14 International Business Machines Corporation Distributed processing of route selection across networks and subnetworks
US5491690A (en) * 1993-07-30 1996-02-13 International Business Machines Corporation Method and apparatus to speed up the path selection in a packet switching network
US5497368A (en) * 1993-08-18 1996-03-05 Koninklijke Ptt Nederland N.V. Routing method for a hierarchical communications network, and a hierarchical communications network having improved routing
US5687168A (en) * 1995-07-19 1997-11-11 Nec Corporation Link state routing device in ATM communication system
US5754790A (en) * 1996-05-01 1998-05-19 3Com Corporation Apparatus and method for selecting improved routing paths in an autonomous system of computer networks
US5930259A (en) * 1995-08-25 1999-07-27 Kabushiki Kaisha Toshiba Packet transmission node device realizing packet transfer scheme and control information transfer scheme using multiple virtual connections
US6003090A (en) * 1997-04-23 1999-12-14 Cabletron Systems, Inc. System for determining network connection availability between source and destination devices for specified time period
US6023501A (en) * 1998-03-03 2000-02-08 Nec Corporation Least cost routing with repeated searches for lower cost route
US6078590A (en) * 1997-07-14 2000-06-20 Cisco Technology, Inc. Hierarchical routing knowledge for multicast packet routing
US6097718A (en) * 1996-01-02 2000-08-01 Cisco Technology, Inc. Snapshot routing with route aging
US6108710A (en) * 1997-11-26 2000-08-22 International Business Machine Corp. Method and apparatus for optimizing route generation in a connection oriented network
US6199170B1 (en) * 1999-05-11 2001-03-06 Trimble Navigation Limited Method and apparatus for precise time synchronization
US6205146B1 (en) * 1998-05-28 2001-03-20 3Com Corporation Method of dynamically routing to a well known address in a network
US6222829B1 (en) * 1997-12-23 2001-04-24 Telefonaktieblaget L M Ericsson Internet protocol telephony for a mobile station on a packet data channel
US20020035641A1 (en) * 1999-07-02 2002-03-21 Yoshitoshi Kurose Service allocating device
US20030026268A1 (en) * 2000-11-28 2003-02-06 Siemens Technology-To-Business Center, Llc Characteristic routing
US20030128710A1 (en) * 1998-12-28 2003-07-10 Fedyk Donald Wayne Quasi-deterministic gateway selection algorithm for multi-domain source routed networks
US20040202158A1 (en) * 2000-12-18 2004-10-14 Hirokazu Takeno Packet communication network and packet transfer control method
US20070165546A1 (en) * 2001-05-21 2007-07-19 Greenberg Albert G Packet-switched network topology tracking method and system
US20090052457A1 (en) * 1998-08-25 2009-02-26 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6119170A (en) 1997-12-29 2000-09-12 Bull Hn Information Systems Inc. Method and apparatus for TCP/IP multihoming on a host system configured with multiple independent transport provider systems
US6363319B1 (en) 1999-08-31 2002-03-26 Nortel Networks Limited Constraint-based route selection using biased cost
US6836463B2 (en) * 1999-10-15 2004-12-28 Nokia Corporation System for communicating labeled routing trees to establish preferred paths and source routes with local identifiers in wireless computer networks

Patent Citations (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5101348A (en) * 1988-06-23 1992-03-31 International Business Machines Corporation Method of reducing the amount of information included in topology database update messages in a data communications network
US4939726A (en) * 1989-07-18 1990-07-03 Metricom, Inc. Method for routing packets in a packet communication network
US5115433A (en) * 1989-07-18 1992-05-19 Metricom, Inc. Method and system for routing packets in a packet communication network
US5323394A (en) * 1992-04-07 1994-06-21 Digital Equipment Corporation Selecting optimal routes in source routing bridging without exponential flooding of explorer packets
US5309433A (en) * 1992-06-18 1994-05-03 International Business Machines Corp. Methods and apparatus for routing packets in packet transmission networks
US5365523A (en) * 1992-11-16 1994-11-15 International Business Machines Corporation Forming and maintaining access groups at the lan/wan interface
US5398012A (en) * 1992-11-24 1995-03-14 International Business Machines Corporation Distributed processing of route selection across networks and subnetworks
US5491690A (en) * 1993-07-30 1996-02-13 International Business Machines Corporation Method and apparatus to speed up the path selection in a packet switching network
US5317566A (en) * 1993-08-18 1994-05-31 Ascom Timeplex Trading Ag Least cost route selection in distributed digital communication networks
US5497368A (en) * 1993-08-18 1996-03-05 Koninklijke Ptt Nederland N.V. Routing method for a hierarchical communications network, and a hierarchical communications network having improved routing
US5687168A (en) * 1995-07-19 1997-11-11 Nec Corporation Link state routing device in ATM communication system
US5930259A (en) * 1995-08-25 1999-07-27 Kabushiki Kaisha Toshiba Packet transmission node device realizing packet transfer scheme and control information transfer scheme using multiple virtual connections
US6097718A (en) * 1996-01-02 2000-08-01 Cisco Technology, Inc. Snapshot routing with route aging
US5754790A (en) * 1996-05-01 1998-05-19 3Com Corporation Apparatus and method for selecting improved routing paths in an autonomous system of computer networks
US6003090A (en) * 1997-04-23 1999-12-14 Cabletron Systems, Inc. System for determining network connection availability between source and destination devices for specified time period
US6078590A (en) * 1997-07-14 2000-06-20 Cisco Technology, Inc. Hierarchical routing knowledge for multicast packet routing
US6108710A (en) * 1997-11-26 2000-08-22 International Business Machine Corp. Method and apparatus for optimizing route generation in a connection oriented network
US6222829B1 (en) * 1997-12-23 2001-04-24 Telefonaktieblaget L M Ericsson Internet protocol telephony for a mobile station on a packet data channel
US6023501A (en) * 1998-03-03 2000-02-08 Nec Corporation Least cost routing with repeated searches for lower cost route
US6205146B1 (en) * 1998-05-28 2001-03-20 3Com Corporation Method of dynamically routing to a well known address in a network
US20090052457A1 (en) * 1998-08-25 2009-02-26 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
US20030128710A1 (en) * 1998-12-28 2003-07-10 Fedyk Donald Wayne Quasi-deterministic gateway selection algorithm for multi-domain source routed networks
US6199170B1 (en) * 1999-05-11 2001-03-06 Trimble Navigation Limited Method and apparatus for precise time synchronization
US20020035641A1 (en) * 1999-07-02 2002-03-21 Yoshitoshi Kurose Service allocating device
US20030026268A1 (en) * 2000-11-28 2003-02-06 Siemens Technology-To-Business Center, Llc Characteristic routing
US20040202158A1 (en) * 2000-12-18 2004-10-14 Hirokazu Takeno Packet communication network and packet transfer control method
US20070165546A1 (en) * 2001-05-21 2007-07-19 Greenberg Albert G Packet-switched network topology tracking method and system

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090168645A1 (en) * 2006-03-22 2009-07-02 Tester Walter S Automated Network Congestion and Trouble Locator and Corrector
US8233905B2 (en) 2007-06-15 2012-07-31 Silver Spring Networks, Inc. Load management in wireless mesh communications networks
US20080310311A1 (en) * 2007-06-15 2008-12-18 George Flammer Method and system for providing network and routing protocols for utility services
US20090003214A1 (en) * 2007-06-15 2009-01-01 Silver Spring Networks, Inc. Load management in wireless mesh communications networks
US20080310377A1 (en) * 2007-06-15 2008-12-18 George Flammer Method and system for providing routing protocols in a frequency hopping spread spectrum network
US8515433B2 (en) 2007-06-15 2013-08-20 Silver Spring Networks, Inc. Load management in wireless mesh communications networks
US8072951B2 (en) 2007-06-15 2011-12-06 Silver Spring Networks, Inc. Method and system for providing routing protocols in a frequency hopping spread spectrum network
US8130700B2 (en) 2007-06-15 2012-03-06 Silver Spring Networks, Inc. Method and system for providing network and routing protocols for utility services
US20090034418A1 (en) * 2007-08-01 2009-02-05 Flammer Iii George Method and system of routing in a utility smart-grid network
US7961740B2 (en) * 2007-08-01 2011-06-14 Silver Spring Networks, Inc. Method and system of routing in a utility smart-grid network
US20090228604A1 (en) * 2008-03-05 2009-09-10 Fujitsu Limited Apparatus and method for calculating communication paths
US8898335B2 (en) * 2008-03-05 2014-11-25 Fujitsu Limited Apparatus and method for calculating communication paths
US20110282996A1 (en) * 2009-11-19 2011-11-17 Yoram Zahavi Method and system for dynamically allocating services for subscribers data traffic
US8886805B2 (en) * 2009-11-19 2014-11-11 Flash Networks, Ltd Method and system for dynamically allocating services for subscribers data traffic
US20150085865A1 (en) * 2009-11-19 2015-03-26 Yoram Zahavi Method and system for dynamically allocating services for subscribers data traffic
US9071505B2 (en) * 2009-11-19 2015-06-30 Flash Networks Ltd Method and system for dynamically allocating services for subscribers data traffic
US11201809B1 (en) * 2013-02-11 2021-12-14 Riverbed Technology, Inc. Network topology generation using traceroute data
US11050821B2 (en) 2017-01-31 2021-06-29 Nchain Licensing Ag Computer-implemented system and method for updating a network's knowledge of the network's topology
US11778021B2 (en) 2017-01-31 2023-10-03 Nchain Licensing Ag Computer-implemented system and method for updating a network's knowledge of the network's topology
US11706078B1 (en) * 2021-03-22 2023-07-18 Two Six Labs, LLC Internet disruption detection

Also Published As

Publication number Publication date
JP2005512393A (en) 2005-04-28
US8218447B2 (en) 2012-07-10
AU2002352874A1 (en) 2003-06-17
US20030099203A1 (en) 2003-05-29
US7525920B2 (en) 2009-04-28
EP1461883A1 (en) 2004-09-29
US6836465B2 (en) 2004-12-28
WO2003049341A1 (en) 2003-06-12
US20050025059A1 (en) 2005-02-03
EP1461883A4 (en) 2008-03-12

Similar Documents

Publication Publication Date Title
US8218447B2 (en) Method and system for path identification in packet networks
EP1461882B1 (en) Method and system for topology construction and path identification in a two-level routing domain operated according to a simple link state routing protocol
US7330435B2 (en) Method and system for topology construction and path identification in a routing domain operated according to a link state routing protocol
CN104168154B (en) The multi-level network system and its construction method of network-oriented Situation Awareness
Haddadi et al. Network topologies: inference, modeling, and generation
Francis et al. IDMaps: A global Internet host distance estimation service
US8549139B2 (en) Method and system for monitoring control signal traffic over a computer network
CN100388695C (en) Monitoring and analytic system for route between domain of internet and its working method
CN1287307C (en) Topology discovery by partitioning multiple discovery techniques
US7706300B2 (en) Method for providing topology awareness information within an IP network
US20160057049A1 (en) System and method for identifying network topology information in multiple areas
US20100091685A1 (en) Method and System for Deducing Network Routes by Querying Routers
US7860024B1 (en) Network monitoring method and system
Bayhan et al. On content indexing for off-path caching in information-centric networks
Amini et al. Issues with inferring Internet topological attributes
Chang et al. On inferring AS-level connectivity from BGP routing tables
KR100971224B1 (en) The system for estimating internet wide path and delay and method therefor
CN117176639B (en) Multi-protocol-based network topology automatic discovery method and device
WO2003049340A2 (en) Method and system for topology construction and path identification in a two-level routing domain operated according to a simple link state routing protocol
Raza et al. Effective iBGP operation without a full mesh topology
Avallone et al. A topology discovery module based on a hybrid methodology
Jones Vulnerability Analysis of the Physical and Logical Network Topology on the US Virgin Islands
CN117176639A (en) Multi-protocol-based network topology automatic discovery method and device
Sani An analysis of the completeness of the internet AS-level topology discovered by route collectors
Kaart et al. The importance of Internet topology measurements

Legal Events

Date Code Title Description
AS Assignment

Owner name: IPTIVIA, INC., PENNSYLVANIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IPSUM NETWORKS, INC.;REEL/FRAME:022548/0729

Effective date: 20060127

Owner name: IPSUM NETWORKS, INC., PENNSYLVANIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RAJAN, RAJENDRAN;GUERIN, ROCH;REEL/FRAME:022548/0494

Effective date: 20021111

AS Assignment

Owner name: CIRCADENCE CORPORATION, COLORADO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IPTIVIA, INC.;REEL/FRAME:022878/0484

Effective date: 20090605

AS Assignment

Owner name: CIRCADENCE CORPORATION, COLORADO

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE APPLICATION SERIAL NO. FROM 12/432,392 TO 12/423,392 PREVIOUSLY RECORDED ON REEL 022878 FRAME 0484;ASSIGNOR:IPTIVIA, INC.;REEL/FRAME:023629/0972

Effective date: 20090605

Owner name: CIRCADENCE CORPORATION, COLORADO

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE APPLICATION SERIAL NO. FROM 12/432,392 TO 12/423,392 PREVIOUSLY RECORDED ON REEL 022878 FRAME 0484. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT OF A METHOD AND SYSTEM FOR PATH IDENTIFICATION IN PACKET NETWORKS; INCLUDING U.S. PATENT APPLICATION 12/423,392.;ASSIGNOR:IPTIVIA, INC.;REEL/FRAME:023629/0972

Effective date: 20090605

AS Assignment

Owner name: DAVID L. ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: CRAIG ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: HOPE E. ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: GABRIEL ASHER 2011 SUSMAN TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: ROBERT G. LAMPHERE TRUST DTD 5/13/93, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: CAROL W. ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: SARAH ASHER 2011 SUSMAN TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: SHOFFNER, JOHN, TENNESSEE

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: VAN VLISSINGEN PROFIT SHARING TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: NANETTE O. LAMPHERE TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: DLWS PARTNERSHIP, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: CHARLES AND SARAH LAMPHERE, JTWRS, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: MATARAZZO, JOSEPH, COLORADO

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: DONALD L. ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: AUGUSTINE FUND, LP, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: WILLIAM ASHER 2011 SUSMAN TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

Owner name: HENRY ASHER 2011 SUSMAN TRUST, ILLINOIS

Free format text: SECURITY AGREEMENT;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:028192/0705

Effective date: 20120501

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: SARAH ASHER 2011 SUSMAN TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: AUGUSTINE FUND, LP, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: MELTON, R. NEAL, TENNESSEE

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: VAN VLISSINGEN PROFIT SHARING TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: GABRIEL ASHER 2011 SUSMAN TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: CAROL W. ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: MATARAZZO, DR. JOSEPH, DR., COLORADO

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: CRAIG ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: PASQUALE, JUDY, NEW YORK

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: WILLIAM ASHER 2011 SUSMAN TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: SHOFFNER, JOHN, TENNESSEE

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: SILVERLEAF CONSULTING, LLC, COLORADO

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: SAINTS CAPITAL IV, LP, CALIFORNIA

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: HARLAN, JOHN, MISSOURI

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: DAVID L. ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: HOPE E. KALINSKI REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: DONALD L. ASHER REVOCABLE TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: C&S LAMPHERE INVESTMENTS, LLC, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: HART, STEPHEN, GEORGIA

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: JTWRS, CHARLES AND SARAH LAMPHERE, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

Owner name: HENRY ASHER 2011 SUSMAN TRUST, ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:034927/0043

Effective date: 20140708

AS Assignment

Owner name: CIRCADENCE CORPORATION, COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNORS:VAN VLISSINGEN PROFIT SHARING TRUST;JTWRS, CHARLES AND SARAH LAMPHERE;C&S LAMPHERE INVESTMENTS, LLC;AND OTHERS;REEL/FRAME:037247/0137

Effective date: 20151117

AS Assignment

Owner name: CIRCADENCE CORPORATION, COLORADO

Free format text: RELEASE BY SECURED PARTY;ASSIGNORS:AUGUSTINE FUND, LP;CAROL W. ASHER REVOCABLE TRUST;LAMPHERE, JTWRS, CHARLES AND SARAH;AND OTHERS;REEL/FRAME:037269/0758

Effective date: 20151117

FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: RUNWAY GROWTH CREDIT FUND INC., ILLINOIS

Free format text: SECURITY INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:047973/0029

Effective date: 20181220

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

FEPP Fee payment procedure

Free format text: 7.5 YR SURCHARGE - LATE PMT W/IN 6 MO, SMALL ENTITY (ORIGINAL EVENT CODE: M2555); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2552); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY

Year of fee payment: 8

AS Assignment

Owner name: SONS OF INNOVATION LLC, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:CIRCADENCE CORPORATION;REEL/FRAME:056106/0493

Effective date: 20210426

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY