US20030198235A1 - Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network - Google Patents

Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network Download PDF

Info

Publication number
US20030198235A1
US20030198235A1 US09/986,532 US98653201A US2003198235A1 US 20030198235 A1 US20030198235 A1 US 20030198235A1 US 98653201 A US98653201 A US 98653201A US 2003198235 A1 US2003198235 A1 US 2003198235A1
Authority
US
United States
Prior art keywords
probing
router
probe
probe message
network
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.)
Abandoned
Application number
US09/986,532
Inventor
Jedrick Weldon
Joshua Osborne
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.)
Verizon Patent and Licensing Inc
Original Assignee
MCI Worldcom 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
Application filed by MCI Worldcom Inc filed Critical MCI Worldcom Inc
Priority to US09/986,532 priority Critical patent/US20030198235A1/en
Publication of US20030198235A1 publication Critical patent/US20030198235A1/en
Assigned to MCI, INC. reassignment MCI, INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: WORLDCOM, INC.
Assigned to WORLDCOM, INC. reassignment WORLDCOM, INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MCI WORLDCOM, INC.
Assigned to MCI LLC reassignment MCI LLC MERGER (SEE DOCUMENT FOR DETAILS). Assignors: MCI INC.
Assigned to VERIZON BUSINESS GLOBAL LLC reassignment VERIZON BUSINESS GLOBAL LLC CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: MCI LLC
Assigned to VERIZON PATENT AND LICENSING INC. reassignment VERIZON PATENT AND LICENSING INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: VERIZON BUSINESS GLOBAL LLC
Assigned to MCI WORLDCOM, INC. reassignment MCI WORLDCOM, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: OSBORNE, JOSHUA, WELDON, PATRICK J
Assigned to VERIZON PATENT AND LICENSING INC. reassignment VERIZON PATENT AND LICENSING INC. CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE PREVIOUSLY RECORDED AT REEL: 032734 FRAME: 0502. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT. Assignors: VERIZON BUSINESS GLOBAL LLC
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • 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/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • 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/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5009Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H04L41/5012Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF] determining service availability, e.g. which services are available at a certain point in time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements
    • 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/34Signalling channels for network management communication

Definitions

  • the present invention relates to apparatuses, methods and computer program products that collect service level agreement (SLA) statistics in communication networks and especially virtual private networks (VPN).
  • SLA service level agreement
  • VPN virtual private networks
  • Communication networks provide an infrastructure by which messages (digital or analog) may be routed from a source to one or more destinations.
  • Proprietary, exclusive networks may be used when messages are to be distributed only between a private set of network nodes.
  • These proprietary networks may span only local regions, and are thus called local area network (LAN).
  • LAN local area network
  • MAN metropolitan area network
  • WAN wide area network
  • VPN Virtual private networks
  • a VPN enables communication among a “community of interests” by enabling private traffic to be passed between at least two nodes within the VPN using a shared communication resource, such as the Internet.
  • the Internet When the Internet is used as a component of the communication network, the VPN is referred to as an “Internet VPN”.
  • ISPs Internet service providers
  • the differentiated services for users of the VPN are contractually governed by an agreement between the ISP and VPN customer in the form of a “service level agreement” (SLA).
  • SLA service level agreement
  • the SLA may include provisions for a predetermined network availability, such as 99.9% average end-to-end availability over a one month period for 10 or more sites, and at least 99.8% average end-to-end network availability over a period of one month for 3 to 9 sites.
  • Network speed is another metric of performance that is typically part of the SLA, where an average network latency may be specified to be 120 milliseconds (ms) for round-trip transmission between VPN sites within the United States or within Europe, for example.
  • Some Internet service providers, such as UUNET will provide a service level guarantee and will credit an account of a VPN customer if the level of service, as defined in the SLA, was not achieved.
  • An optional feature in VPNs is the availability of encryption for data packets so that unintended “listeners” will not be able to decipher the information content of the messages sent through the commonly available information channel.
  • tunneling (sometimes referred to as “encapsulation”) encloses a first data packet in a new packet by appending a new header (transmitted in an unencrypted format) to the first data packet, so the network routes the new packet based on the information contained in the new header.
  • the first data packet is usually encrypted when contained in the new data packet so no information can be gleaned from it, except by the intended recipient.
  • the encapsulated packets travel through the network until they reach the destination identified in the new header. At the destination, the new header is stripped away and the first data packet is decrypted and processed.
  • the tunneling and encryption may employ DES and 3DES standards-based technology for transferring data between network locations more securely via an OC-48 TCP/IP infrastructure, for example.
  • FIG. 1 shows an example conventional VPN with a source probe 1 and destination probe 3 that cooperate to collect network SLA statistics.
  • the source probe 1 is hosted on a personal computer using a UNIX operation system, for example, and has a particular IP address.
  • the source probe 1 prepares a 1-packet probe (probe message) that is sent through a source router 7 and then through the network 17 to the destination probe 3 .
  • the source probe 1 includes in the probe message a time stamp, indicating the time at which the source probe 1 sent the probe message.
  • the source router 7 which is maintained on a customer's site with the source probe 1 , has a different IP address than the source probe 1 .
  • the router 7 also handles signals for terminals on a source LAN 10 , which itself has a different IP address. As with the source probe 1 , source router 7 and source LAN 10 , the destination probe 3 , destination router 13 and destination LAN 12 all have unique IP addresses.
  • the network 17 includes routers 9 that are interconnected by way of lines 4 . Likewise, routers 5 are interconnected by lines 2 . Interconnections between routers 9 and 5 are not shown to help illustrate the point that there are different physical paths that a packet may follow through the network 17 when traveling from the source probe 1 to the destination probe 3 .
  • the actual path that a particular packet follows i.e., an “in-band” path, or channel
  • the actual path that a particular packet follows will be influenced by the source/destination pair included in its header. Because the source/destination pair will vary depending which device is generating the packet and which device is receiving the packet, packets handled by the source router 7 and ultimately headed through destination router 13 may follow different routes through the network 17 .
  • Routers 5 and 9 in the network include routing tables that direct how certain packets are routed, and thus these routers may handle one packet from the source probe 1 , different from a packet generated by a terminal on the source LAN 10 .
  • a data packet from the source LAN 10 may follow a path through the routers 5 and lines 2 (“in-band” path) while the probe message may follow a path through the routers 9 and lines 4 (i.e., not “in-band”).
  • the two paths may be the same, although there is no guarantee.
  • the operation of sending the probe message and collecting statistics is now described.
  • the probe message is formed and sent from the source probe 1 at a predetermined time and a time stamp of the send time is included in the probe message.
  • the destination probe 3 recognizes that the probe message has been received.
  • the destination probe 3 then sends a reply probe message to the source probe 1 , and includes information in the reply probe message regarding the time that the destination probe 3 took between receiving the probe message and transmitting the reply probe message.
  • the reply probe message includes the time stamp inserted by the source probe 1 and the remote latency caused by the destination probe 3 .
  • the source router 7 and the destination router 13 may be 4500 CISCO routers that are configured to receive packets from both the source LAN 10 as well as the source probe 1 .
  • the source router 7 is generic in operation and is a separate network component hosted in a separate housing from the source probe 1 .
  • Availability is one of the SLA statistics that is collected by way of the probing process. Because availability relates to a measurement that is taken over a period of time (or over a number of discrete events), the source probe 1 is configured to set a polling interval at 2.5 minutes so as to provide two measurements for a 5 minute window, and therefore provide a 5 minute resolution with regard to the availability statistic.
  • the present inventors recognized that the VPN architecture shown in FIG. 1 is suboptimal in that it does not offer the desired flexibility and scaleability features that would allow for independent upgrading and maintenance of the shared network 17 .
  • the present inventors have recognized that the shared network 17 may be reconfigured and upgraded for future operations. In doing so, it is even possible that additional nodes may be added to the VPN, or even the service level agreement may vary from time to time. Accordingly, it is a limitation with the VPN shown in FIG. 1 that the source probe 1 and destination probe 3 are “hard-wired” to operate at certain polling intervals.
  • the source and destination probes do not necessarily send the probe messages in-band (i.e., over the same physical path traversed by data packets sent between the source LAN 10 and the destination LAN 12 ), even though the SLA is tied to the performance of the in-band channel.
  • an object of the present invention is to overcome these and other limitations by providing a software reconfigurable probing router.
  • a feature of the present invention is to include a probing router at both the source site and the destination site such that the probing operation is performed within the router housing itself, using processing resources available from the router.
  • the probing operation is performed in software (although hardware/firmware/software combinations are alternatives as well) so that changes in the core network and SLA statistic collection processes may be quickly and easily accomplished.
  • the probing router sends the probe message through the same path as the data, thus providing a direct measurement of SLA data.
  • an operations center connected to the network enables a remote “VPN builder” to remotely configure each of the probing routers in the VPN, so that within a short period of time the topology of the VPN may be enabled by informing each of the probing routers of the statistic collection obligation it has and communicating and replying to probe messages with other probing routers in the VPN.
  • the operation center enables a remote probe poller processor to receive, compile, and calculate SLA statistics for the VPN. The statistics may be collected at rates consistent with the SLA for the particular VPN.
  • the operating center enables a SLA reporting system to report data collected by the probe poller processor in a format that is convenient for the VPN customer to verify that the SLA metrics were in fact complied with during a particular operation cycle.
  • FIG. 1 is a block diagram of a conventional VPN that includes separate routers and destination probes;
  • FIG. 2 is a block diagram of a VPN that employs a probing router according to the present invention
  • FIGS. 3 a - 3 c respectively represent data structures for a packet data unit for an Internet protocol packet employed as part of the present invention, as well as data structures for a probe message and reply probe message according to the present invention;
  • FIG. 4 is a block diagram of components of a probing router according to the present invention.
  • FIG. 5 is a flowchart of a process for employing the probing routers so as to collect SLA statistics according to the present invention.
  • FIG. 6 is a flowchart of a process for configuring and collecting SLA statistic information according to the present invention.
  • FIG. 2 is a block diagram of a VPN and supporting components according to the present invention.
  • Data from a terminal (i.e., data source) node at a source LAN 210 is sent by way of a source VPN probing router 207 through a network 217 , which may be the Internet or another shared network, to a destination VPN probing router 203 (sometimes referred to as “PR”) and finally to a destination LAN 208 .
  • the network 217 is a shared resource such as the Internet. However other types of networks may be used that employ TCP/IP, or a related packet switched protocol such as IP version 4 or IP version 6 .
  • the physical medium in the network 217 may be made of any combination of terrestrial ground lines, optical lines, or wireless links that will form the in-band channel 204 or other channel paths 206 for example.
  • Various nodes are hosted in the network 217 that may be configured to become part of the VPN, as will be discussed. These nodes are served by routers 205 and 209 for example. For convenience, lines 204 are shown with a darker line indicating that this is the path through which the source LAN 210 and destination LAN 208 communicate with one another in a first scenario. Dynamic routing tables in the routers 209 and 205 dictate the path to be followed by the message traffic (whether encapsulated or not), where the chosen path is affected by the source/destination pair included in the message traffic header.
  • both probe packets and encapsulated data packets will traverse the same path.
  • the SLA statistics will be determined from in-band channel measurements since the probe message traverses the same path as the data packets.
  • the source VPN probing router 207 need only connect to the source LAN 210 , but not a separate source probe 1 as was the case with the configuration in FIG. 1.
  • the source VPN probing router 207 relays message traffic between the source LAN 210 and the network 217 according to conventional routing operations.
  • the router includes program memory that holds therein instructions that are executed by a processor to form a probe mechanism that, at programmable time intervals, generates a packet data unit (a probe message) for transmitting through the in-band channel 204 to the destination router 203 .
  • the probe message includes a time stamp that indicates the time at which the source VPN probing router 207 actually sends the message over the in-band channel 204 to the destination VPN router 203 .
  • the time stamp is stored and retained by the VPN probing router 207 .
  • the polling interval at which the source VPN probing router 207 sends the probe messages is set by a VPN operation center 221 (VPNOC) that downloads a control instruction to the source VPN probing router 207 .
  • the control instruction includes an appropriate time interval indicator (polling interval) used for performing the probing operation.
  • the probe message after having passed through the in-band channel 204 , is received at the destination VPN probing router 203 , which identifies the probe message and subsequently prepares a reply probe message along with data (i.e., remote latency data) regarding the amount of time it took the destination VPN probing router 203 to prepare and send the reply probe message back to the source VPN probing router 207 .
  • the source VPN probing router 207 stores the data contained therein but ultimately will send the data retrieved from the probe message in the reply probe message to the probe poller processor 223 , which is connected to the VPNOC 221 .
  • Part of the remote latency for the destination VPN probing router 203 is a time required to perform the tunneling operation for deencapsulating and subsequently encapsulating the probe message and reply probe message respectively.
  • the system shown in FIG. 2 is able to offer several advantages.
  • One advantage is that separate hardware components are not required to perform the probing and routing operations, but rather the resources available from the router 207 are employed for performing the probing operation.
  • the parameters of the probing operation are software settable, and may be remotely adjusted from the VPNOC 221 , and usually from the QVPN builder 227 .
  • One advantage of including the probing operations in the source VPN router is that additional components need not be maintained at a customer's premise.
  • the processing demands of the probing operations are sufficiently small with respect to those performed in a traditional router such that sufficient processing power and memory are available for performing the probing operation.
  • Including the probing operations within a router 207 assists in offering a more flexible and scalable architecture than the conventional approach.
  • SLA statistic collection parameters may be altered by the QVPN builder 227 by changing software settings in the probing router which allows for upgrades in equipment at the source site or the destination site to be upgraded quickly and efficiently when changes to the SLA statistic collection operation are desired.
  • the inventive system helps to achieve a goal of isolating the functions performed in the network 217 from those performed at the source site or the destination site. Consequently, the operator of the network 217 may upgrade the network independent of whether any changes are made at the source site or the destination site.
  • the isolation of the functionality performed by the network 217 and that performed by a source equipment or destination equipment is accomplished by isolating “core” communication transport functions performed in the network 217 from node-specific operations performed at different nodes connected to the network, such as at the source site. In this way, the network 217 may be upgraded separate from the equipment at the source site or the destination site.
  • any reprogramming of the VPN probing routers is accomplished by configuration commands sent from the QVPN builder.
  • the VPNOC 221 hosts the QVPN builder, which is a software-based mechanism used to configure VPN topology, set security profiles and distribute keys to each VPN site in an automatic fashion. Consequently, adding new VPN sites or adding more tunnels to the VPN is quickly performed since all of the probing routers may be adjusted in operation by control instructions sent from the QVPN builder. Accordingly, network operators do not need to manually secure IPSec tunnels for each of the IP nodes required to communicate over the VPN.
  • the VPN builder in the network architecture as shown with the use of VPN probing routers 207 and 203 and other probing routers, it is possible to easily scale a VPN according to customer requirements.
  • the probe poller processor 223 which is also hosted in the VPNOC 221 , is able to receive SLA statistics data from the source and destination VP probing routers. The probe poller processor 223 then calculates an average total return time R tt for transmission of a probe message and return of a reply probe message according to the equation:
  • R tt is round trip time of a probe message and reply probe message
  • T 2 is a time at which the reply probe message is received from the destination probing router
  • T 1 is a time at which the probe message is sent from the source VPN probing router
  • R L is remote latency, which refers to the amount of time that the destination VPN probing router requires to prepare and send the reply probe message in response to receiving the probe message.
  • the probe poller processor 223 is implemented in software and executed on a processor, but may also be implemented in any combination of hardware and/or firmware such as with an application specific integrated circuit.
  • the probe poller processor 223 determines that an availability outage occurred when two adjacent packets are observed as being lost. However, other availability calculations may be performed as well, such as by determining availability on a packet by packet basis. A particular packet is viewed as being lost if R tt exceeds a predetermined amount.
  • a packet-loss rate may be determined by observing a number of total packets sent within a predetermined time period, perhaps within a five minute window, or even a one month window, and determining a ratio of the number of reply probe messages received versus the number of probe messages sent.
  • availability may be calculated as [number of probe messages sent—dropped packets]/[total number of probe messages sent]. Availability may be determined in a variety of other ways, such as whether a predetermined number of packets are dropped within a predetermined period of time (for example two packets dropped in 5 minutes, where the polling interval is 2.5 minutes).
  • a Probe Poll List is maintained as an ASCII text file. This file can be called as a parameter by the probe poller processor on startup. If a file parameter is passed, this overrides any Probe Poll List maintained in a preference file. Additional probes can be configured directly through a configuration edit display. Through the menu options for this screen, the user can add, delete or import Probes to the Probe Poll List.
  • the default Probe Poll List resides in the root level application directory called, probeList.txt. This file can be created with any standard text editor.
  • the Probe Poll List file is organized by VPN. The VPN is defined (created) as:
  • VPN ⁇ vpn name>
  • ⁇ vpn name> is the name of the current VPN.
  • a line of text follows to define the required probing router parameters.
  • Each probing router parameter line begins with:
  • NAME ⁇ sysName> The sysName of the probing router. This is set by the probe poller processor during the initial poll sequence.
  • SNMP ⁇ version> V2 for snmpV2 access or V3 for snmpV3 access.
  • TIMEOUT ⁇ value> The snmp timeout value for requests to this probing router.
  • RETRIES ⁇ value> The snmp retry value for requests to this probing router.
  • USER ⁇ user name> The snmpV3 user id.
  • AUTHPROTO The snmpV3 authentication protocol ⁇ authentication to use: NONE, MD5, or SHA. protocol>
  • AUTHPWD The snmpV3 authentication password. ⁇ authentication password>
  • the file contents and data structure saved in memory of each record saved in the VPN probing router is as follows: Field Description DstIP IP address of the remote PR to receive the probe packet dstPort Port on which the remote PR listens SrcIP IP address of the PR probe which initiates the probe packet srcPort Port on which the PR probe listens seqstart Timestamp assigned when the PR probe initializes seqcount Next sequential counter for this remote PR send- Timestamp when the PR probe initiates a probe seconds packet send-ms Coupled with send-seconds B microseconds recv- Timestamp when the PR probe receives the probe seconds packet response from the remote PR recv-ms Coupled with recv-seconds - microseconds remote- Number of microseconds spent processing the process-ms sample packet on the remote PR to turn around a response packet
  • the probing routers may generate SNMP Traps when the number of packets lost in a predetermined amount of time exceeds a predetermined threshold, and if the probe latency is measured as exceeding a predetermined time.
  • SLA statistical data compiled by the probe poller processor 223 is provided to the SLA reporting system 225 .
  • the SLA reporting system 225 provides to a customer a condensed aggregation of data collected by the probe poller processor 223 so that the customer may review whether the SLA was complied with during the reporting interval.
  • the SLA system 225 aggregates the data on a month-by-month basis and provides the data via a server on an Internet web-site for review by customers of the VPN.
  • a computer and printer are employed to provide written reports summarizing the SLA statistics that were collected for the customer of the VPN.
  • the probing operations are performed on the network 217 at layer 3 (i.e., IP layer).
  • the operation is performed independent of the physical and data link layers and thus may be used in any one of a variety of different network configurations such as frame relay, ATM, FDDI, packet-over SONET, Ethernet, fibre channel as well as others.
  • a description of example network systems that may be employed with the current invention is provided in “Data and Computer Communications”, by William Stallings, Fifth Ed., Prentice Hall, Chapter pages 401-458, 1997, the entire contents of which being incorporated herein by reference.
  • Chapters 15 and 16 provide further description of specific protocols and architectures that may be employed with the present invention, and thus Chapters 15-16, pages 497-584 are also incorporated herein by reference.
  • encryption may be employed to improve information privacy, encryption need not be employed and thus is an optional feature, selected by a customer when subscribing to the VPN service.
  • the source VPN probing router 207 may also employ multi-protocol label switching that prioritizes packets through the core communication network 217 .
  • FIG. 3 a illustrates a generic protocol data unit for a probe message sent by the source VPN probing router 207 according to the present invention. Consistent with the operation of TCP/IP, IP header 301 a and IP data area 301 b form part of an IP datagram portion of a network-level packet 303 .
  • the network-level packet 303 includes a frame header 303 a and a frame data area 303 b.
  • FIG. 3 b shows a functional description (i.e., those data fields that are relevant to the present probing discussion) of an IP datagram portion of the packet employed for the probe message.
  • IP header 301 a is followed by a source time stamp 321 b, which is placed in the IP data area portion of the IP datagram 321 .
  • This source time stamp T1 is transmitted in the probe message to the destination VPN probing router 203 .
  • the source VPN probing router does not include the time stamp T1, but does save the time stamp in memory for later use after the reply probe message is received.
  • FIG. 3 c shows the IP datagram for the reply probe message.
  • the IP datagram 331 includes a field 331 a that holds a measurement value (an indicator) of the remote latency R L as being equal to R 2 -R 1 , where R 2 is the time that the destination VPN probing router sent the reply probe message, and R 1 is the time at which the probe message was received by the destination VPN probing router 203 .
  • the remote latency R L is the difference between these two times and measures the amount of time that was required by the destination VPN probing router 203 to generate and send the reply probe message after receiving the probe message.
  • the reply probe message also includes the source time stamp T1 321 b. The source probing router 207 then receives the reply probe message at time T2.
  • FIG. 4 represents the internal components of a source VPN probing router according to the present invention.
  • the probing router includes a data bus 403 that interconnects a processor 405 with other components connected to the bus 403 .
  • the processor 405 executes computer readable instructions saved on ROM 409 to implement both a routing engine 477 as well as the programmable probe device 407 .
  • the main memory 408 is a RAM that receives software settable parameters sent from the QVPN builder 227 (FIG. 2) for setting the probing parameters that would be executed by the programmable probe device 407 .
  • the programmable probe device 407 is shown to be internal to the processor 405 , which is the case when it is implemented only in software, but may also be a separate component that communications with the other components by the bus, or other signal relaying mechanism, such as a local bus or optical link.
  • the programmable probe device includes a timer that generates a probe message after a predetermined time has elapsed since the last probe message was sent.
  • the programmable probe device 407 either maintains internally thereto, or retrieves from main memory 408 , a polling interval parameter that was set by the QVPN builder 227 . Furthermore, the programmable probe device 407 also receives an indication from the QVPN builder 227 which destination VPN probing routers the source VPN is to communicate with so that tunnels may be established therebetween.
  • a storage device 410 is also a RAM and is used to hold information regarding round trip delay and whether packets are dropped. This information is later sent to the probe poller processor 223 , either on demand from the probe poller processor 223 or at periodic intervals as a software settable parameter and saved in main memory 408 .
  • the packet grouping logic 417 and envelope packet logic 419 cooperate to form IP packets for assessing whether received packets are to be routed to a device connected to the router, or not.
  • the packet grouping logic 417 and envelope packet logic 419 cooperate to form packets for sending over the IP network 417 by way of the input/output unit 415 .
  • a buffer unit 413 serves as a buffer for saving and holding message traffic when the processor 405 is busy (for inbound messages) or for sending packets when either the input/output unit 415 is busy or the IP network 417 is busy.
  • the input/output 415 connects by way of a bus 421 to the IP network 417 .
  • a local source terminal 450 also connects to the input/output unit 415 for local accessability to the router.
  • the IP network 417 and source terminal 450 connect through ports (or connectors) to the housing 401 .
  • FIG. 5 is a flowchart showing a process flow for collecting SLA statistics over the VPN.
  • the process begins in step 501 where an inquiry is made regarding whether a predetermined time period has elapsed since the source VPN probing router has sent the last probe message. If the response to the inquiry is negative, the inquiry is made again until the time period has in fact elapsed. Once the response to the inquiry is affirmative, the process proceeds to step 503 where the source VPN probing router sends a polling packet to the destination VPN probing router 203 .
  • the polling packet (probe message) optionally includes a time stamp T1 therein. Alternatively, the source VPN probing router simply stores in memory the time at which the polling packet has been sent, thus not notifying the destination VPN probing router when the message was in fact sent.
  • step 505 the process proceeds to step 505 where the probe message is received at a time R 1 at the destination VPN probing router.
  • the process then proceeds to step 507 where the remote latency (or processing delay) R L is inserted in the reply probe message and the reply probe message is then sent.
  • step S 507 the process proceeds to step S 509 where the programmable probe device 407 (FIG. 4) compares the amount of time between when the probe message was sent (T1) and when (if at all) a reply probe message is received (T2). In step 509 if it is determined that the difference between T2 and T1 is greater than a predetermined amount (a software settable parameter) then it is determined that the packet (probe message) was dropped. If the packet was dropped, the process proceeds to step S 511 where an indication is saved in memory 410 (FIG. 4), or sent directly to the probe poller processor 223 (FIG. 2) indicating that a packet was dropped. The process then proceeds to step S 519 .
  • a predetermined amount a software settable parameter
  • the probe poller processor 223 gathers information from the respective probing routers in the VPN and calculates average round-trip time, R tt , availability, and packet loss rate for each tunnel as well as for the entire VPN. After having collected these SLA statistics, the process proceeds to step S 521 where an inquiry is made regarding whether an SLA performance is judged to be below a required level, typically the service level agreement threshold levels. If the response to the inquiry in step 521 is negative, the process repeats so as to maintain a SLA statistical retrieval monitoring process. On the other hand, if the response to the inquiry in step 521 is affirmative, the process proceeds to step 523 where corrective action is taken on the network resources.
  • This may include dispatching a trouble-shooting technician to identify a source of the problem or adjusting the software settable parameters in the probing router, so as to be less stringent on the service level requirements imposed on the network.
  • the corrective action may also include providing a refund to a client, if the service level agreement statistics were in fact below the required level. After step 523 the process then repeats so as to continue the SLA statistic collection and analysis operation.
  • FIG. 6 is a flowchart of a process for automatically and remotely configuring a VPN architecture according to customer-specified requirements.
  • the process begins in step S 601 where the QVPN builder 227 is provided with VPN topology configuration information, which identifies the different VPN nodes that will be used in the customer-specified VPN.
  • the process then proceeds to step S 603 where the probing routers are either manually assigned a polling interval, or a default setting is included, such as two minute intervals.
  • the process then proceeds to step 605 where the QVPN builder 227 sends configuration messages to the respective probing routers by way of the network 217 .
  • the probing routers then set the software settable parameters for the programmable probe device 407 either in the main memory 408 or in the programmable probe device itself.
  • step S 605 the process proceeds to step S 607 , where the programmable probe device 407 (FIG. 4), causes the SLA statistical data that is saved in the storage device 410 to be sent to the probe poller processor 223 (FIG. 2).
  • the probe poller processor 223 creates a database in the probe polling processor and holds the data therein for calculation and distillation of SLA statistical data.
  • the process proceeds to step 609 where the QVPN builder 227 dispatches a “configuration” message to respective of the programmable probe devices in the probing routers.
  • the configuration messages include the software settable parameters used by the probing routers to determine the polling interval, dropped packet threshold decision time, and other parameters such as particular node addresses to which to communicate with in determining round-trip time for packet transmission.
  • the process proceeds to step S 611 where the configuration messages are received at each of the programmable probe devices and the programmable probe devices employ the parameters contained therein to perform probing operations at the polling interval identified in the configuration message. Subsequently the configuration process ends.
  • the present invention thus also includes a computer-based product that may be hosted on a storage medium and include instructions that can be used to program a computer to perform a process in accordance with the present invention.
  • the storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, flash memory, magneto or optical cards, or any type of media suitable for storing electronic instructions.

Abstract

A probing router is used at a source site of a virtual private network. In-band probing operations are performed by components within the probing router, using processing resources available from a router engine portion of the probing router. In this way, changes in the network and service level agreement statistic collection processes may be quickly and easily accommodated within the probing router. Furthermore, the probing router communicates the probe message through an in-band communication channel so as to provide a direct measurement of service level data for the channel used for communicating information between the source site and a destination site.

Description

    BACKGROUND OF THE INVENTION
  • 1. Field of the Invention [0001]
  • The present invention relates to apparatuses, methods and computer program products that collect service level agreement (SLA) statistics in communication networks and especially virtual private networks (VPN). [0002]
  • 2. Discussion of the Background [0003]
  • Communication networks provide an infrastructure by which messages (digital or analog) may be routed from a source to one or more destinations. Proprietary, exclusive networks may be used when messages are to be distributed only between a private set of network nodes. These proprietary networks may span only local regions, and are thus called local area network (LAN). Similarly, such proprietary networks may extend across a single city, and thus may be referred to as a metropolitan area network (MAN). When extending over a larger geographic region, where the nodes are separated by relatively large distances, the network is referred to as a wide area network (WAN). [0004]
  • However, the expense of establishing and maintaining a proprietary network whether it be a LAN, MAN or a WAN, is often not cost effective. Furthermore, maintaining the network often requires personnel with specialized skills, having job descriptions that may be well outside the scope of the company's main line of business. While the proprietary network does offer the advantages of dedicated security and avoidance of traffic congestion problems, the expense and maintenance issues associated with developing proprietary, exclusive-use networks is not often justifiable, particularly when publicly available resources are available, such as the Internet. [0005]
  • Virtual private networks (VPN) provide a cost effective alternative to proprietary networks. A VPN enables communication among a “community of interests” by enabling private traffic to be passed between at least two nodes within the VPN using a shared communication resource, such as the Internet. When the Internet is used as a component of the communication network, the VPN is referred to as an “Internet VPN”. However, unlike un-regulated and uncontrolled communications over the Internet, a VPN is usually established by Internet service providers (ISPs), who provide differentiated services from other users who are not part of the VPN. The differentiated services for users of the VPN, are contractually governed by an agreement between the ISP and VPN customer in the form of a “service level agreement” (SLA). [0006]
  • The SLA may include provisions for a predetermined network availability, such as 99.9% average end-to-end availability over a one month period for 10 or more sites, and at least 99.8% average end-to-end network availability over a period of one month for 3 to 9 sites. Network speed is another metric of performance that is typically part of the SLA, where an average network latency may be specified to be 120 milliseconds (ms) for round-trip transmission between VPN sites within the United States or within Europe, for example. Some Internet service providers, such as UUNET will provide a service level guarantee and will credit an account of a VPN customer if the level of service, as defined in the SLA, was not achieved. An optional feature in VPNs is the availability of encryption for data packets so that unintended “listeners” will not be able to decipher the information content of the messages sent through the commonly available information channel. [0007]
  • VPNs, and in particular Internet VPNs, often choose to employ tunneling technology as a way to securely transfer data between two similar networks (e.g., private LANs) over an intermediate network such as UUNET net IP network. Tunneling (sometimes referred to as “encapsulation”) encloses a first data packet in a new packet by appending a new header (transmitted in an unencrypted format) to the first data packet, so the network routes the new packet based on the information contained in the new header. The first data packet is usually encrypted when contained in the new data packet so no information can be gleaned from it, except by the intended recipient. The encapsulated packets travel through the network until they reach the destination identified in the new header. At the destination, the new header is stripped away and the first data packet is decrypted and processed. The tunneling and encryption may employ DES and 3DES standards-based technology for transferring data between network locations more securely via an OC-48 TCP/IP infrastructure, for example. [0008]
  • As determined by the inventors, several advantages to Internet VPNs include improved privacy, reduced cost relative to dedicated leased lines, and an improved coverage area, largely owing to the availability of the global reach of the Internet. [0009]
  • As recognized by the present inventors, conventional Internet VPNs are suboptimal in flexibility and scaleability. FIG. 1, shows an example conventional VPN with a source probe [0010] 1 and destination probe 3 that cooperate to collect network SLA statistics. The source probe 1 is hosted on a personal computer using a UNIX operation system, for example, and has a particular IP address. The source probe 1 prepares a 1-packet probe (probe message) that is sent through a source router 7 and then through the network 17 to the destination probe 3. The source probe 1 includes in the probe message a time stamp, indicating the time at which the source probe 1 sent the probe message. The source router 7, which is maintained on a customer's site with the source probe 1, has a different IP address than the source probe 1. The router 7 also handles signals for terminals on a source LAN 10, which itself has a different IP address. As with the source probe 1, source router 7 and source LAN 10, the destination probe 3, destination router 13 and destination LAN 12 all have unique IP addresses.
  • The [0011] network 17 includes routers 9 that are interconnected by way of lines 4. Likewise, routers 5 are interconnected by lines 2. Interconnections between routers 9 and 5 are not shown to help illustrate the point that there are different physical paths that a packet may follow through the network 17 when traveling from the source probe 1 to the destination probe 3. The actual path that a particular packet follows (i.e., an “in-band” path, or channel) will be influenced by the source/destination pair included in its header. Because the source/destination pair will vary depending which device is generating the packet and which device is receiving the packet, packets handled by the source router 7 and ultimately headed through destination router 13 may follow different routes through the network 17. Routers 5 and 9 in the network include routing tables that direct how certain packets are routed, and thus these routers may handle one packet from the source probe 1, different from a packet generated by a terminal on the source LAN 10. Thus, a data packet from the source LAN 10 may follow a path through the routers 5 and lines 2 (“in-band” path) while the probe message may follow a path through the routers 9 and lines 4 (i.e., not “in-band”). Of course, the two paths may be the same, although there is no guarantee.
  • The operation of sending the probe message and collecting statistics is now described. The probe message is formed and sent from the source probe [0012] 1 at a predetermined time and a time stamp of the send time is included in the probe message. Once the probe message is passed through the network 17 and by the destination router 13 to the destination probe 3, the destination probe 3 recognizes that the probe message has been received. The destination probe 3 then sends a reply probe message to the source probe 1, and includes information in the reply probe message regarding the time that the destination probe 3 took between receiving the probe message and transmitting the reply probe message. Thus, the reply probe message includes the time stamp inserted by the source probe 1 and the remote latency caused by the destination probe 3. In this way, when the source probe 1 receives the reply probe message it is possible to determine the round trip time between when the source probe 1 originally sent the probe message and the time that the reply probe message was received by the source probe 1, less the remote latency time. The source router 7 and the destination router 13 may be 4500 CISCO routers that are configured to receive packets from both the source LAN 10 as well as the source probe 1. Thus, the source router 7 is generic in operation and is a separate network component hosted in a separate housing from the source probe 1.
  • Availability is one of the SLA statistics that is collected by way of the probing process. Because availability relates to a measurement that is taken over a period of time (or over a number of discrete events), the source probe [0013] 1 is configured to set a polling interval at 2.5 minutes so as to provide two measurements for a 5 minute window, and therefore provide a 5 minute resolution with regard to the availability statistic.
  • The present inventors recognized that the VPN architecture shown in FIG. 1 is suboptimal in that it does not offer the desired flexibility and scaleability features that would allow for independent upgrading and maintenance of the shared [0014] network 17. The present inventors have recognized that the shared network 17 may be reconfigured and upgraded for future operations. In doing so, it is even possible that additional nodes may be added to the VPN, or even the service level agreement may vary from time to time. Accordingly, it is a limitation with the VPN shown in FIG. 1 that the source probe 1 and destination probe 3 are “hard-wired” to operate at certain polling intervals. Furthermore, the source and destination probes do not necessarily send the probe messages in-band (i.e., over the same physical path traversed by data packets sent between the source LAN 10 and the destination LAN 12), even though the SLA is tied to the performance of the in-band channel.
  • Accordingly, by having the source probe [0015] 1, as well as the destination probe 2, implemented in a separate computer outside of the source router 7 and having a separate IP address, operators of the VPN are therefore limited by the capabilities of the source probe 1 to accurately collect SLA statistics. This is especially problematic when changes are to be made to the “core” shared network 17. Furthermore, the amount of space required to host the source probe 1, the source LAN 10 and the router 7, adds to maintainability restrictions at the source site.
  • SUMMARY OF THE INVENTION
  • In light of the above-discussed and other limitations of conventional systems and methods for collecting SLA statistics, an object of the present invention is to overcome these and other limitations by providing a software reconfigurable probing router. [0016]
  • A feature of the present invention is to include a probing router at both the source site and the destination site such that the probing operation is performed within the router housing itself, using processing resources available from the router. In this way, the probing operation is performed in software (although hardware/firmware/software combinations are alternatives as well) so that changes in the core network and SLA statistic collection processes may be quickly and easily accomplished. Furthermore, the probing router sends the probe message through the same path as the data, thus providing a direct measurement of SLA data. [0017]
  • Another feature of the present invention is that an operations center connected to the network enables a remote “VPN builder” to remotely configure each of the probing routers in the VPN, so that within a short period of time the topology of the VPN may be enabled by informing each of the probing routers of the statistic collection obligation it has and communicating and replying to probe messages with other probing routers in the VPN. Furthermore, the operation center enables a remote probe poller processor to receive, compile, and calculate SLA statistics for the VPN. The statistics may be collected at rates consistent with the SLA for the particular VPN. Furthermore, the operating center enables a SLA reporting system to report data collected by the probe poller processor in a format that is convenient for the VPN customer to verify that the SLA metrics were in fact complied with during a particular operation cycle. [0018]
  • Other features and advantages of the present invention will become readily apparent from the following detailed description when read in conjunction with the accompanying drawings.[0019]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A more complete appreciation of the present invention and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein: [0020]
  • FIG. 1 is a block diagram of a conventional VPN that includes separate routers and destination probes; [0021]
  • FIG. 2 is a block diagram of a VPN that employs a probing router according to the present invention; [0022]
  • FIGS. 3[0023] a-3 c respectively represent data structures for a packet data unit for an Internet protocol packet employed as part of the present invention, as well as data structures for a probe message and reply probe message according to the present invention;
  • FIG. 4 is a block diagram of components of a probing router according to the present invention; [0024]
  • FIG. 5 is a flowchart of a process for employing the probing routers so as to collect SLA statistics according to the present invention; and [0025]
  • FIG. 6 is a flowchart of a process for configuring and collecting SLA statistic information according to the present invention. [0026]
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
  • Referring now to the drawings, specific terminology will be employed for the sake of clarity. However, the present invention is not intended to be limited to the specific terminology so selected and it is to be understood that each of the elements referred to in the specification are intended to include all technical equivalents that operate in a similar manner. [0027]
  • FIG. 2 is a block diagram of a VPN and supporting components according to the present invention. Data from a terminal (i.e., data source) node at a [0028] source LAN 210 is sent by way of a source VPN probing router 207 through a network 217, which may be the Internet or another shared network, to a destination VPN probing router 203 (sometimes referred to as “PR”) and finally to a destination LAN 208. The network 217 is a shared resource such as the Internet. However other types of networks may be used that employ TCP/IP, or a related packet switched protocol such as IP version 4 or IP version 6. The physical medium in the network 217 may be made of any combination of terrestrial ground lines, optical lines, or wireless links that will form the in-band channel 204 or other channel paths 206 for example. Various nodes are hosted in the network 217 that may be configured to become part of the VPN, as will be discussed. These nodes are served by routers 205 and 209 for example. For convenience, lines 204 are shown with a darker line indicating that this is the path through which the source LAN 210 and destination LAN 208 communicate with one another in a first scenario. Dynamic routing tables in the routers 209 and 205 dictate the path to be followed by the message traffic (whether encapsulated or not), where the chosen path is affected by the source/destination pair included in the message traffic header. Since the source VPN probing router 207 and the destination VPN probing router 203 both have IP addresses that may be used as header source/destination pairs in headers of encapsulated packets, both probe packets and encapsulated data packets will traverse the same path. As a consequence, the SLA statistics will be determined from in-band channel measurements since the probe message traverses the same path as the data packets.
  • As can be seen, at the site where the [0029] source LAN 210 and source VPN probing router 207 are located, the source VPN probing router 207 need only connect to the source LAN 210, but not a separate source probe 1 as was the case with the configuration in FIG. 1. The source VPN probing router 207 relays message traffic between the source LAN 210 and the network 217 according to conventional routing operations. In addition, the router includes program memory that holds therein instructions that are executed by a processor to form a probe mechanism that, at programmable time intervals, generates a packet data unit (a probe message) for transmitting through the in-band channel 204 to the destination router 203. The probe message includes a time stamp that indicates the time at which the source VPN probing router 207 actually sends the message over the in-band channel 204 to the destination VPN router 203. Alternatively, the time stamp is stored and retained by the VPN probing router 207.
  • The polling interval at which the source [0030] VPN probing router 207 sends the probe messages is set by a VPN operation center 221 (VPNOC) that downloads a control instruction to the source VPN probing router 207. The control instruction includes an appropriate time interval indicator (polling interval) used for performing the probing operation. The probe message, after having passed through the in-band channel 204, is received at the destination VPN probing router 203, which identifies the probe message and subsequently prepares a reply probe message along with data (i.e., remote latency data) regarding the amount of time it took the destination VPN probing router 203 to prepare and send the reply probe message back to the source VPN probing router 207. Once the source VPN probing router 207 receives the reply probe message, the source VPN probing router 207 stores the data contained therein but ultimately will send the data retrieved from the probe message in the reply probe message to the probe poller processor 223, which is connected to the VPNOC 221. Part of the remote latency for the destination VPN probing router 203 is a time required to perform the tunneling operation for deencapsulating and subsequently encapsulating the probe message and reply probe message respectively.
  • By implementing the probing operations in software in the source VPN router, and making the probing operations software reconfigurable, the system shown in FIG. 2 is able to offer several advantages. One advantage is that separate hardware components are not required to perform the probing and routing operations, but rather the resources available from the [0031] router 207 are employed for performing the probing operation. Furthermore, the parameters of the probing operation are software settable, and may be remotely adjusted from the VPNOC 221, and usually from the QVPN builder 227. One advantage of including the probing operations in the source VPN router is that additional components need not be maintained at a customer's premise. Furthermore, the processing demands of the probing operations are sufficiently small with respect to those performed in a traditional router such that sufficient processing power and memory are available for performing the probing operation.
  • Including the probing operations within a [0032] router 207, assists in offering a more flexible and scalable architecture than the conventional approach. For example, SLA statistic collection parameters may be altered by the QVPN builder 227 by changing software settings in the probing router which allows for upgrades in equipment at the source site or the destination site to be upgraded quickly and efficiently when changes to the SLA statistic collection operation are desired. Furthermore, the inventive system helps to achieve a goal of isolating the functions performed in the network 217 from those performed at the source site or the destination site. Consequently, the operator of the network 217 may upgrade the network independent of whether any changes are made at the source site or the destination site. The isolation of the functionality performed by the network 217 and that performed by a source equipment or destination equipment is accomplished by isolating “core” communication transport functions performed in the network 217 from node-specific operations performed at different nodes connected to the network, such as at the source site. In this way, the network 217 may be upgraded separate from the equipment at the source site or the destination site. Once the core network is changed, any reprogramming of the VPN probing routers is accomplished by configuration commands sent from the QVPN builder.
  • The [0033] VPNOC 221 hosts the QVPN builder, which is a software-based mechanism used to configure VPN topology, set security profiles and distribute keys to each VPN site in an automatic fashion. Consequently, adding new VPN sites or adding more tunnels to the VPN is quickly performed since all of the probing routers may be adjusted in operation by control instructions sent from the QVPN builder. Accordingly, network operators do not need to manually secure IPSec tunnels for each of the IP nodes required to communicate over the VPN. By employing the VPN builder in the network architecture as shown with the use of VPN probing routers 207 and 203 and other probing routers, it is possible to easily scale a VPN according to customer requirements.
  • The [0034] probe poller processor 223, which is also hosted in the VPNOC 221, is able to receive SLA statistics data from the source and destination VP probing routers. The probe poller processor 223 then calculates an average total return time Rtt for transmission of a probe message and return of a reply probe message according to the equation:
  • R tt=(T 2 −T 1)−R L,
  • where R[0035] tt is round trip time of a probe message and reply probe message, T2 is a time at which the reply probe message is received from the destination probing router, T1 is a time at which the probe message is sent from the source VPN probing router and RL is remote latency, which refers to the amount of time that the destination VPN probing router requires to prepare and send the reply probe message in response to receiving the probe message.
  • The [0036] probe poller processor 223 is implemented in software and executed on a processor, but may also be implemented in any combination of hardware and/or firmware such as with an application specific integrated circuit. The probe poller processor 223 determines that an availability outage occurred when two adjacent packets are observed as being lost. However, other availability calculations may be performed as well, such as by determining availability on a packet by packet basis. A particular packet is viewed as being lost if Rtt exceeds a predetermined amount. A packet-loss rate may be determined by observing a number of total packets sent within a predetermined time period, perhaps within a five minute window, or even a one month window, and determining a ratio of the number of reply probe messages received versus the number of probe messages sent. By collecting and saving packet-loss information on a packet by packet basis, availability may be calculated as [number of probe messages sent—dropped packets]/[total number of probe messages sent]. Availability may be determined in a variety of other ways, such as whether a predetermined number of packets are dropped within a predetermined period of time (for example two packets dropped in 5 minutes, where the polling interval is 2.5 minutes).
  • More particular implementation details are now described. A Probe Poll List is maintained as an ASCII text file. This file can be called as a parameter by the probe poller processor on startup. If a file parameter is passed, this overrides any Probe Poll List maintained in a preference file. Additional probes can be configured directly through a configuration edit display. Through the menu options for this screen, the user can add, delete or import Probes to the Probe Poll List. The default Probe Poll List resides in the root level application directory called, probeList.txt. This file can be created with any standard text editor. The Probe Poll List file is organized by VPN. The VPN is defined (created) as: [0037]
  • VPN=<vpn name>[0038]
  • Where <vpn name> is the name of the current VPN. For each probing router associated with this VPN, a line of text follows to define the required probing router parameters. Each probing router parameter line begins with: [0039]
  • PR=<ip address>[0040]
  • Additional parameters are optional and all parameters are delimited by colons. Any missing parameters will be set by defaults in the application when the Probe Poll List is parsed. [0041]
    Parameter Description
    NAME=<sysName> The sysName of the probing router.
    This is set by the probe poller
    processor during the initial poll
    sequence.
    SNMP=<version> V2 for snmpV2 access or V3 for
    snmpV3 access.
    COMMUNITY= The snmpV2 community string.
    <community string>
    PORT=<snmp port> This defaults to 161.
    TIMEOUT=<value> The snmp timeout value for requests
    to this probing router.
    RETRIES=<value> The snmp retry value for requests to
    this probing router.
    USER=<user name> The snmpV3 user id.
    AUTHPROTO= The snmpV3 authentication protocol
    <authentication to use: NONE, MD5, or SHA.
    protocol>
    AUTHPWD= The snmpV3 authentication password.
    <authentication
    password>
  • Probe Poller Processor Output Format [0042]
  • The characteristics of the latency logs are as follows: [0043]
  • File Name: latency.log.<timestamp when file closed>.gz [0044]
  • Directory Structure on the Monitoring System Server: [0045]
  • $VPNLOGS/vpnlogs-<collector process pid>-<sequenctial counter>/<probe hostname>/<vpn name>[0046]
  • File Characteristics: ASCII, colon delimited fields, compressed with gzip, lines beginning with “#” are comment fields, All time stamps are UTC, a “$” character is output on the last line to terminate the file. [0047]
  • The file contents and data structure saved in memory of each record saved in the VPN probing router is as follows: [0048]
    Field Description
    DstIP IP address of the remote PR to receive the probe
    packet
    dstPort Port on which the remote PR listens
    SrcIP IP address of the PR probe which initiates the
    probe packet
    srcPort Port on which the PR probe listens
    seqstart Timestamp assigned when the PR probe
    initializes
    seqcount Next sequential counter for this remote PR
    send- Timestamp when the PR probe initiates a probe
    seconds packet
    send-ms Coupled with send-seconds B microseconds
    recv- Timestamp when the PR probe receives the probe
    seconds packet response from the remote PR
    recv-ms Coupled with recv-seconds - microseconds
    remote- Number of microseconds spent processing the
    process-ms sample packet on the remote PR to turn around a
    response packet
    Flags Bit 1 indicates packet type:
     0 = data; 1 = test
  • The probing routers may generate SNMP Traps when the number of packets lost in a predetermined amount of time exceeds a predetermined threshold, and if the probe latency is measured as exceeding a predetermined time. [0049]
  • SLA statistical data compiled by the [0050] probe poller processor 223 is provided to the SLA reporting system 225. The SLA reporting system 225 provides to a customer a condensed aggregation of data collected by the probe poller processor 223 so that the customer may review whether the SLA was complied with during the reporting interval. In one embodiment, the SLA system 225 aggregates the data on a month-by-month basis and provides the data via a server on an Internet web-site for review by customers of the VPN. Alternatively, a computer and printer are employed to provide written reports summarizing the SLA statistics that were collected for the customer of the VPN.
  • The probing operations are performed on the [0051] network 217 at layer 3 (i.e., IP layer). Thus, the operation is performed independent of the physical and data link layers and thus may be used in any one of a variety of different network configurations such as frame relay, ATM, FDDI, packet-over SONET, Ethernet, fibre channel as well as others. A description of example network systems that may be employed with the current invention is provided in “Data and Computer Communications”, by William Stallings, Fifth Ed., Prentice Hall, Chapter pages 401-458, 1997, the entire contents of which being incorporated herein by reference. Furthermore, Chapters 15 and 16 provide further description of specific protocols and architectures that may be employed with the present invention, and thus Chapters 15-16, pages 497-584 are also incorporated herein by reference.
  • While encryption may be employed to improve information privacy, encryption need not be employed and thus is an optional feature, selected by a customer when subscribing to the VPN service. The source VPN probing [0052] router 207 may also employ multi-protocol label switching that prioritizes packets through the core communication network 217.
  • FIG. 3[0053] a illustrates a generic protocol data unit for a probe message sent by the source VPN probing router 207 according to the present invention. Consistent with the operation of TCP/IP, IP header 301 a and IP data area 301 b form part of an IP datagram portion of a network-level packet 303. The network-level packet 303 includes a frame header 303 a and a frame data area 303 b.
  • FIG. 3[0054] b shows a functional description (i.e., those data fields that are relevant to the present probing discussion) of an IP datagram portion of the packet employed for the probe message. IP header 301 a is followed by a source time stamp 321 b, which is placed in the IP data area portion of the IP datagram 321. This source time stamp T1 is transmitted in the probe message to the destination VPN probing router 203. Alternatively, the source VPN probing router does not include the time stamp T1, but does save the time stamp in memory for later use after the reply probe message is received.
  • FIG. 3[0055] c shows the IP datagram for the reply probe message. As shown, the IP datagram 331 includes a field 331 a that holds a measurement value (an indicator) of the remote latency RL as being equal to R2-R1, where R2 is the time that the destination VPN probing router sent the reply probe message, and R1 is the time at which the probe message was received by the destination VPN probing router 203. Accordingly, the remote latency RL is the difference between these two times and measures the amount of time that was required by the destination VPN probing router 203 to generate and send the reply probe message after receiving the probe message. The reply probe message also includes the source time stamp T1 321 b. The source probing router 207 then receives the reply probe message at time T2.
  • FIG. 4 represents the internal components of a source VPN probing router according to the present invention. Within a [0056] housing 401, the probing router includes a data bus 403 that interconnects a processor 405 with other components connected to the bus 403. In particular, the processor 405 executes computer readable instructions saved on ROM 409 to implement both a routing engine 477 as well as the programmable probe device 407.
  • The [0057] main memory 408 is a RAM that receives software settable parameters sent from the QVPN builder 227 (FIG. 2) for setting the probing parameters that would be executed by the programmable probe device 407. The programmable probe device 407 is shown to be internal to the processor 405, which is the case when it is implemented only in software, but may also be a separate component that communications with the other components by the bus, or other signal relaying mechanism, such as a local bus or optical link. The programmable probe device includes a timer that generates a probe message after a predetermined time has elapsed since the last probe message was sent. The programmable probe device 407 either maintains internally thereto, or retrieves from main memory 408, a polling interval parameter that was set by the QVPN builder 227. Furthermore, the programmable probe device 407 also receives an indication from the QVPN builder 227 which destination VPN probing routers the source VPN is to communicate with so that tunnels may be established therebetween.
  • A [0058] storage device 410 is also a RAM and is used to hold information regarding round trip delay and whether packets are dropped. This information is later sent to the probe poller processor 223, either on demand from the probe poller processor 223 or at periodic intervals as a software settable parameter and saved in main memory 408. The packet grouping logic 417 and envelope packet logic 419 cooperate to form IP packets for assessing whether received packets are to be routed to a device connected to the router, or not. Likewise, the packet grouping logic 417 and envelope packet logic 419 cooperate to form packets for sending over the IP network 417 by way of the input/output unit 415. A buffer unit 413 serves as a buffer for saving and holding message traffic when the processor 405 is busy (for inbound messages) or for sending packets when either the input/output unit 415 is busy or the IP network 417 is busy. The input/output 415 connects by way of a bus 421 to the IP network 417. A local source terminal 450 also connects to the input/output unit 415 for local accessability to the router. The IP network 417 and source terminal 450 connect through ports (or connectors) to the housing 401.
  • FIG. 5 is a flowchart showing a process flow for collecting SLA statistics over the VPN. The process begins in step [0059] 501 where an inquiry is made regarding whether a predetermined time period has elapsed since the source VPN probing router has sent the last probe message. If the response to the inquiry is negative, the inquiry is made again until the time period has in fact elapsed. Once the response to the inquiry is affirmative, the process proceeds to step 503 where the source VPN probing router sends a polling packet to the destination VPN probing router 203. The polling packet (probe message) optionally includes a time stamp T1 therein. Alternatively, the source VPN probing router simply stores in memory the time at which the polling packet has been sent, thus not notifying the destination VPN probing router when the message was in fact sent.
  • After step [0060] 503, the process proceeds to step 505 where the probe message is received at a time R1 at the destination VPN probing router. The destination VPN probing router then prepares a reply probe message and sends the reply probe message at a time R2 such that the remote latency (i.e., turn-around time of the destination VPN probing router) is given by RL=R2-R1. The process then proceeds to step 507 where the remote latency (or processing delay) RL is inserted in the reply probe message and the reply probe message is then sent.
  • After step S[0061] 507, the process proceeds to step S509 where the programmable probe device 407 (FIG. 4) compares the amount of time between when the probe message was sent (T1) and when (if at all) a reply probe message is received (T2). In step 509 if it is determined that the difference between T2 and T1 is greater than a predetermined amount (a software settable parameter) then it is determined that the packet (probe message) was dropped. If the packet was dropped, the process proceeds to step S511 where an indication is saved in memory 410 (FIG. 4), or sent directly to the probe poller processor 223 (FIG. 2) indicating that a packet was dropped. The process then proceeds to step S519.
  • If however, the response to the inquiry in step S[0062] 509 is negative, the process proceeds to step 513 where the time stamp T2 is determined from when the reply packet (reply probe message) is received and the process then proceeds to step S515 where a round-trip time Rtt is calculated. The calculation for round-trip time is determined as Rtt=(T2-T1)−RL. The process then proceeds to step S517 where Rtt is stored in memory at the probing router, although alternatively the data may be sent directly to the probe poller processor 223 at the VPNOC 221.
  • The [0063] probe poller processor 223 gathers information from the respective probing routers in the VPN and calculates average round-trip time, Rtt, availability, and packet loss rate for each tunnel as well as for the entire VPN. After having collected these SLA statistics, the process proceeds to step S521 where an inquiry is made regarding whether an SLA performance is judged to be below a required level, typically the service level agreement threshold levels. If the response to the inquiry in step 521 is negative, the process repeats so as to maintain a SLA statistical retrieval monitoring process. On the other hand, if the response to the inquiry in step 521 is affirmative, the process proceeds to step 523 where corrective action is taken on the network resources. This may include dispatching a trouble-shooting technician to identify a source of the problem or adjusting the software settable parameters in the probing router, so as to be less stringent on the service level requirements imposed on the network. The corrective action may also include providing a refund to a client, if the service level agreement statistics were in fact below the required level. After step 523 the process then repeats so as to continue the SLA statistic collection and analysis operation.
  • FIG. 6 is a flowchart of a process for automatically and remotely configuring a VPN architecture according to customer-specified requirements. The process begins in step S[0064] 601 where the QVPN builder 227 is provided with VPN topology configuration information, which identifies the different VPN nodes that will be used in the customer-specified VPN. The process then proceeds to step S603 where the probing routers are either manually assigned a polling interval, or a default setting is included, such as two minute intervals. The process then proceeds to step 605 where the QVPN builder 227 sends configuration messages to the respective probing routers by way of the network 217. The probing routers then set the software settable parameters for the programmable probe device 407 either in the main memory 408 or in the programmable probe device itself.
  • After step S[0065] 605 the process proceeds to step S607, where the programmable probe device 407 (FIG. 4), causes the SLA statistical data that is saved in the storage device 410 to be sent to the probe poller processor 223 (FIG. 2). The probe poller processor 223 creates a database in the probe polling processor and holds the data therein for calculation and distillation of SLA statistical data.
  • In the event that changes are required in the network, the process proceeds to step [0066] 609 where the QVPN builder 227 dispatches a “configuration” message to respective of the programmable probe devices in the probing routers. The configuration messages include the software settable parameters used by the probing routers to determine the polling interval, dropped packet threshold decision time, and other parameters such as particular node addresses to which to communicate with in determining round-trip time for packet transmission. Once the configuration messages are dispatched, the process proceeds to step S611 where the configuration messages are received at each of the programmable probe devices and the programmable probe devices employ the parameters contained therein to perform probing operations at the polling interval identified in the configuration message. Subsequently the configuration process ends.
  • The processes and control mechanisms set forth in the present description may be implemented using conventional general purpose microprocessors in the routers that are programmed according to the teachings of the present specification, as will be appreciated to those skilled in the relevant art(s). Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will also be apparent to those skilled in the relevant art(s). [0067]
  • The present invention thus also includes a computer-based product that may be hosted on a storage medium and include instructions that can be used to program a computer to perform a process in accordance with the present invention. The storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, flash memory, magneto or optical cards, or any type of media suitable for storing electronic instructions. [0068]
  • Numerous additional modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein. [0069]

Claims (23)

1. A probing router comprising:
a bus;
a routing engine coupled to the bus and configured to forward packets to a communications network;
a communication network port coupled to the bus and configured to connect to a communication network and transmit a probe message and the packets therethrough; and
a probe mechanism configured to generate and send the probe message through said communication network port to the communication network at a time T1, said probe mechanism sending the probe message over an in-band communication channel.
2. The probing router of claim 1, wherein:
said probe mechanism being configured to receive a reply probe message at a second time, T2, sent by a destination router in response to receiving said probe message with a remote latency indicator therein so that service level agreement characteristics may subsequently be derived by comparing T1, T2 and the remote latency indicator.
3. The probing router of claim 2, further comprising:
a memory, wherein
the probe mechanism being configured to identify and store in the memory the service level agreement characteristics.
4. The probing router of claim 1, wherein:
said in-band channel being a tunnel channel in a virtual private network.
5. The probing router of claim 2, wherein:
said reply probe message including a data field configured to hold the remote latency indicator that represents an amount of time between when said destination router received said probe message and when said destination router sent said reply probe message.
6. The probing router of claim 1, wherein:
a polling interval at which said probe mechanism sends said probe message being a remotely programmable setting.
7. The probing router of claim 3, wherein:
said probe mechanism being configured to send at least one of T1, T2, and the remote latency indicator to a probe poller device that calculates service level agreement statistics.
8. The probing router of claim 7, wherein:
said probe mechanism being configured to calculate service level agreement statistics based on T1, T2, and the remote latency, said service level agreement statistics including at least one of a network availability statistic and a packet loss rate.
9. A computer-readable medium carrying one or more sequences of one or more instructions for sending a probe message, the one or more sequences of one or more instructions including instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of:
(a) preparing a probe message; and
(b) sending said probe message over an in-band communication channel.
10. The computer-readable medium according to claim 9, wherein the probe message includes a time stamp, T1, representing when said probe message is sent in said sending step.
11. The computer-readable medium according to claim 10, wherein when the one or more instructions are executed by the one or more processors cause the one or more processors to further perform the steps of:
receiving at a second time, T2, a reply probe message sent from a destination probing router; and
extracting a remote latency indicator from said reply probe message, said remote latency indicator representing an amount of time between when said destination probing router received said probe message and when said destination probing router sent said reply probe message.
12. The computer-readable medium of claim 11, wherein when the one or more instructions are executed by the one or more processors cause the one or more processors to further perform the step of:
calculating service level agreement statistics associated with the in-band communication channel of the virtual private communication network from T1, T2 and said remote latency indicator.
13. The computer-readable medium of claim 9, wherein said in-band channel being an in-band channel of a virtual private network.
14. A communication system for gathering traffic statistics, comprising:
a probing router configured to prepare performance statistics information;
a probe poller processor configured to receive performance statistics information collected by a probing router that sends a probe message through an in-band channel; and
a reporting mechanism coupled to said probe poller processor and configured to present a compilation of said performance statistics information for comparison against performance thresholds of a service level agreement.
15. The system of claim 14, wherein said in-band channel being in a virtual private network.
16. The system of claim 14, wherein said probing router being within a customer premise.
17. The system of claim 14, wherein said reporting mechanism being configured to report said performance statistics information in at least one of a printed form and a graphically displayed form.
18. The system of claim 14, wherein said reporting mechanism being configured to report said performance statistics on an Internet web site.
19. The system of claim 14, further comprising:
a virtual private network builder configured to receive topology information regarding an assignment of probing routers to the virtual private network and produce a control signal to be distributed to respective probing routers, said probing router being one of said probing routers.
20. The virtual private network operation center of claim 19, wherein:
said control signal including a polling interval indicator that sets a polling interval at which said probing router sends said probe message.
21. The virtual private network operation center of claim 14, wherein:
said probe poller processor being configured to calculate at least one of an availability and a packet loss rate of said in-band communication channel from said performance statistics information.
22. A probing router comprising:
means for routing data packets within a virtual private network;
means for preparing and sending a probe message through an in-band channel of the virtual private network; and
an enclosure that houses said means for routing and said means for preparing and sending.
23. A method for collecting network performance statistics, comprising the steps of:
(a) preparing a probe message with a probing router;
(b) sending said probe message over an in-band communication channel; and
(c) measuring a propagation time for said probe message to reach a predetermined location.
US09/986,532 1999-12-22 2001-11-09 Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network Abandoned US20030198235A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US09/986,532 US20030198235A1 (en) 1999-12-22 2001-11-09 Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US09/469,507 US6366563B1 (en) 1999-12-22 1999-12-22 Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network
US09/986,532 US20030198235A1 (en) 1999-12-22 2001-11-09 Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US09/469,507 Continuation US6366563B1 (en) 1999-12-22 1999-12-22 Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network

Publications (1)

Publication Number Publication Date
US20030198235A1 true US20030198235A1 (en) 2003-10-23

Family

ID=23864053

Family Applications (2)

Application Number Title Priority Date Filing Date
US09/469,507 Expired - Lifetime US6366563B1 (en) 1999-12-22 1999-12-22 Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network
US09/986,532 Abandoned US20030198235A1 (en) 1999-12-22 2001-11-09 Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US09/469,507 Expired - Lifetime US6366563B1 (en) 1999-12-22 1999-12-22 Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network

Country Status (3)

Country Link
US (2) US6366563B1 (en)
AU (1) AU2595401A (en)
WO (1) WO2001047190A1 (en)

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030009444A1 (en) * 2001-06-14 2003-01-09 Eidler Christopher William Secured shared storage architecture
US20030055972A1 (en) * 2001-07-09 2003-03-20 Fuller William Tracy Methods and systems for shared storage virtualization
US20030187828A1 (en) * 2002-03-21 2003-10-02 International Business Machines Corporation Method and system for dynamically adjusting performance measurements according to provided service level
US20030187972A1 (en) * 2002-03-21 2003-10-02 International Business Machines Corporation Method and system for dynamically adjusting performance measurements according to provided service level
US20030214955A1 (en) * 2002-05-14 2003-11-20 Samsung Electronics Co., Ltd. Apparatus and method for offering connections between network devices located in different home networks
US20040054680A1 (en) * 2002-06-13 2004-03-18 Netscout Systems, Inc. Real-time network performance monitoring system and related methods
US20050135231A1 (en) * 2003-12-19 2005-06-23 At&T Corporation Routing protocols with predicted outage notification
US20050198262A1 (en) * 2004-01-14 2005-09-08 Jon Barry Method and system for measuring remote-access VPN quality of service
US20050286538A1 (en) * 2004-06-29 2005-12-29 Alcatel Method and call server for establishing a bi-directional peer-to-peer communication link
US20060008535A1 (en) * 2004-07-09 2006-01-12 Robert Sabin Anti tumor compositions and methods of use
US20060171509A1 (en) * 2004-12-22 2006-08-03 International Business Machines Corporation Method and system for managing service levels provided by service providers
US20060176809A1 (en) * 2005-02-07 2006-08-10 Hong Kong University Of Science And Technology Non-blocking internet backbone network
US20070041329A1 (en) * 2005-08-22 2007-02-22 Sbc Knowledge Ventures, L.P. System and method for monitoring a switched metro ethernet network
US20070076615A1 (en) * 2005-10-03 2007-04-05 The Hong Kong University Of Science And Technology Non-Blocking Destination-Based Routing Networks
US7228255B2 (en) 2004-12-22 2007-06-05 International Business Machines Corporation Adjudication means in method and system for managing service levels provided by service providers
US20070268882A1 (en) * 2006-05-22 2007-11-22 Lee Breslau Method for implementing and reporting one-way network measurements
US20080081051A1 (en) * 2006-09-28 2008-04-03 Robert Sabin Method of manufacturing anti-tumor and anti-viral compositions
US20080095171A1 (en) * 2006-10-19 2008-04-24 Electronics And Telecommunications Research Institute Method and system for confirming connection of layer-1 label switched path(L1-LSP) in GMPLS-based network
US20080189353A1 (en) * 2003-08-01 2008-08-07 Gray Eric W Systems and methods for inferring services on a network
US20090046583A1 (en) * 2007-08-13 2009-02-19 Henry Towster Methods and apparatus to control traffic in a packet-switched network
US20090086645A1 (en) * 2003-01-07 2009-04-02 Exfo Service Assurance, Inc. Apparatus and method for passively analyzing a data packet delivery path
US20090105850A1 (en) * 2007-08-31 2009-04-23 Yokogawa Electric Corporation Field control system and field control method
US7555408B2 (en) 2004-12-22 2009-06-30 International Business Machines Corporation Qualifying means in method and system for managing service levels provided by service providers
US20100036810A1 (en) * 2008-08-08 2010-02-11 Oracle International Corporation Automated topology-based statistics monitoring and performance analysis
US7697568B1 (en) * 2003-03-03 2010-04-13 Cisco Technology, Inc. Method and system for automatic modem bandwidth detection in a router
US7848337B1 (en) * 2006-11-14 2010-12-07 Cisco Technology, Inc. Auto probing endpoints for performance and fault management
WO2015034564A1 (en) * 2013-09-06 2015-03-12 Nec Laboratories America, Inc. Patent latency monitoring in software-defined networks

Families Citing this family (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6912232B1 (en) * 1998-10-19 2005-06-28 At&T Corp. Virtual private network
JP3587352B2 (en) * 1999-02-04 2004-11-10 富士通株式会社 Network communication performance measurement method and apparatus, and computer-readable recording medium storing network communication performance measurement program
US7072964B1 (en) * 1999-08-31 2006-07-04 Science Applications International Corporation System and method for interconnecting multiple virtual private networks
US6643287B1 (en) * 1999-11-24 2003-11-04 Pluris, Inc. Apparatus and method for forwarding encapsulated data packets on a network having multiple links between nodes
US6745242B1 (en) * 1999-11-30 2004-06-01 Verizon Corporate Services Group Inc. Connectivity service-level guarantee monitoring and claim validation systems and methods
US6661778B1 (en) * 2000-03-13 2003-12-09 Alcatel Canada Inc. Method and apparatus for statistics collection in a data communication network
US7016309B1 (en) * 2000-04-12 2006-03-21 Cisco Technology, Inc. Method and apparatus for calculating packet loss for a communication circuit
FI112148B (en) * 2000-07-24 2003-10-31 Stonesoft Oyj Procedure for checking data transfer
US7840692B1 (en) * 2000-08-15 2010-11-23 Ciena Corporation System, device, and method for bandwidth management in an optical communication system
US6807515B2 (en) 2000-09-15 2004-10-19 Telephia, Inc. Wireless network monitoring
US7664119B2 (en) * 2001-03-30 2010-02-16 Intel Corporation Method and apparatus to perform network routing
US7054274B2 (en) * 2001-04-11 2006-05-30 Alcatel Canada Inc. Method and apparatus for processing requests for statistics in a communication network
US20030074473A1 (en) * 2001-10-12 2003-04-17 Duc Pham Scalable network gateway processor architecture
US7013342B2 (en) * 2001-12-10 2006-03-14 Packeteer, Inc. Dynamic tunnel probing in a communications network
WO2004027580A2 (en) * 2002-09-20 2004-04-01 Nortel Networks Limited System and method for managing an optical networking service
NZ523378A (en) * 2002-12-24 2005-02-25 Yellowtuna Holdings Ltd Network device without configuration data and a method of configuring the network device from a remote verification authority
US7583607B2 (en) * 2003-03-06 2009-09-01 Hewlett-Packard Development Company, L.P. Method and apparatus for designating and implementing support level agreements
US20040221003A1 (en) * 2003-04-30 2004-11-04 Steele Douglas W. System and method for transmitting supporting requests in a data center with a support meta language
US7873527B2 (en) * 2003-05-14 2011-01-18 International Business Machines Corporation Insurance for service level agreements in e-utilities and other e-service environments
US7606887B1 (en) 2003-09-11 2009-10-20 Juniper Networks, Inc. Automatic establishment of network performance monitoring communities using routing protocols
US8295175B2 (en) * 2003-09-30 2012-10-23 Ciena Corporation Service metrics for managing services transported over circuit-oriented and connectionless networks
US20050223111A1 (en) * 2003-11-04 2005-10-06 Nehru Bhandaru Secure, standards-based communications across a wide-area network
US20050144273A1 (en) * 2003-12-03 2005-06-30 Asit Dan Electronic contracts for devices and embedded systems
US8346909B2 (en) * 2004-01-22 2013-01-01 International Business Machines Corporation Method for supporting transaction and parallel application workloads across multiple domains based on service level agreements
US20050188075A1 (en) * 2004-01-22 2005-08-25 International Business Machines Corporation System and method for supporting transaction and parallel services in a clustered system based on a service level agreement
US20050177660A1 (en) * 2004-02-05 2005-08-11 Rajesh Mamidwar Method and system for merged rate-smoothing buffer with burst buffer
US7489683B2 (en) * 2004-09-29 2009-02-10 Intel Corporation Integrated circuit capable of routing multicast data packets using device vectors
US7684390B2 (en) * 2004-12-30 2010-03-23 Intel Corporation Integrated circuit capable of transmitting probe packets across a stack of switches
US7373661B2 (en) * 2005-02-14 2008-05-13 Ethome, Inc. Systems and methods for automatically configuring and managing network devices and virtual private networks
US7409709B2 (en) * 2005-02-14 2008-08-05 Etsec, Inc. Systems and methods for automatically reconfiguring a network device
US7969896B2 (en) * 2006-08-29 2011-06-28 Cisco Technology, Inc. Method and system for providing connectivity outage detection for MPLS core networks based on service level agreement
US8631115B2 (en) * 2006-10-16 2014-01-14 Cisco Technology, Inc. Connectivity outage detection: network/IP SLA probes reporting business impact information
US8041785B2 (en) * 2007-01-17 2011-10-18 Microsoft Corporation Programmatically choosing a router configuration provider
US8923141B2 (en) * 2007-03-16 2014-12-30 Cisco Technology, Inc. Providing clock synchronization in a network
US8005000B1 (en) * 2007-04-06 2011-08-23 Cisco Technology, Inc. Effective measurement/notification of SLA in a service oriented networked environment
US8416763B1 (en) 2008-11-14 2013-04-09 Cisco Technology, Inc. System and method for providing quality inter-domain network time transport
JP2011065273A (en) * 2009-09-15 2011-03-31 Ricoh Co Ltd Apparatus, system, method and program for managing equipment, and storage medium
US8880684B2 (en) * 2010-07-23 2014-11-04 Broadcom Corporation Method and system for measuring individual network round-trip delays in IP gateways
US9397900B2 (en) * 2010-09-27 2016-07-19 Coriant Operations, Inc. Methods and apparatus for sharing counter resources between CoS/priority or/and between EVC/VLAN to support frame loss measurement
US9112733B2 (en) 2010-11-22 2015-08-18 International Business Machines Corporation Managing service level agreements using statistical process control in a networked computing environment
CN106416137B (en) * 2013-10-16 2019-07-26 柏思科技有限公司 For showing the method and system of network performance information
US10263807B2 (en) * 2016-12-19 2019-04-16 Ciena Corporation Hierarchical statistics acceleration

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6445681B1 (en) * 1999-09-15 2002-09-03 Vocaltec Communications Ltd. Method for measuring delay parameters in a network
US6493349B1 (en) * 1998-11-13 2002-12-10 Nortel Networks Limited Extended internet protocol virtual private network architectures
US6512761B1 (en) * 1999-02-02 2003-01-28 3Com Corporation System for adjusting billing for real-time media transmissions based on delay

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5930257A (en) * 1996-01-25 1999-07-27 Baynetworks, Inc. Network router that routes internetwork packets between distinct networks coupled to the same physical interface using the physical interface
US5886643A (en) * 1996-09-17 1999-03-23 Concord Communications Incorporated Method and apparatus for discovering network topology
US5867483A (en) * 1996-11-12 1999-02-02 Visual Networks, Inc. Method and apparatus for measurement of peak throughput in packetized data networks
US5878032A (en) * 1997-11-07 1999-03-02 Northern Telecom Limited Delay monitoring of telecommunication networks
US6058102A (en) * 1997-11-07 2000-05-02 Visual Networks Technologies, Inc. Method and apparatus for performing service level analysis of communications network performance metrics

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6493349B1 (en) * 1998-11-13 2002-12-10 Nortel Networks Limited Extended internet protocol virtual private network architectures
US6512761B1 (en) * 1999-02-02 2003-01-28 3Com Corporation System for adjusting billing for real-time media transmissions based on delay
US6445681B1 (en) * 1999-09-15 2002-09-03 Vocaltec Communications Ltd. Method for measuring delay parameters in a network

Cited By (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030009444A1 (en) * 2001-06-14 2003-01-09 Eidler Christopher William Secured shared storage architecture
US7693970B2 (en) * 2001-06-14 2010-04-06 Savvis Communications Corporation Secured shared storage architecture
US20030055972A1 (en) * 2001-07-09 2003-03-20 Fuller William Tracy Methods and systems for shared storage virtualization
US7734781B2 (en) 2001-07-09 2010-06-08 Savvis Communications Corporation Methods and systems for shared storage virtualization
US6931356B2 (en) * 2002-03-21 2005-08-16 International Business Machines Corporation System for dynamically adjusting performance measurements according to provided service level
US20030187828A1 (en) * 2002-03-21 2003-10-02 International Business Machines Corporation Method and system for dynamically adjusting performance measurements according to provided service level
US20030187972A1 (en) * 2002-03-21 2003-10-02 International Business Machines Corporation Method and system for dynamically adjusting performance measurements according to provided service level
US6928394B2 (en) * 2002-03-21 2005-08-09 International Business Machines Corporation Method for dynamically adjusting performance measurements according to provided service level
US20030214955A1 (en) * 2002-05-14 2003-11-20 Samsung Electronics Co., Ltd. Apparatus and method for offering connections between network devices located in different home networks
US7796616B2 (en) * 2002-05-14 2010-09-14 Samsung Electronics Co., Ltd. Apparatus and method for offering connections between network devices located in different home networks
US7711751B2 (en) * 2002-06-13 2010-05-04 Netscout Systems, Inc. Real-time network performance monitoring system and related methods
US20040054680A1 (en) * 2002-06-13 2004-03-18 Netscout Systems, Inc. Real-time network performance monitoring system and related methods
US20090086645A1 (en) * 2003-01-07 2009-04-02 Exfo Service Assurance, Inc. Apparatus and method for passively analyzing a data packet delivery path
US7840670B2 (en) * 2003-01-07 2010-11-23 Exfo Service Assurance, Inc. Apparatus and method for passively analyzing a data packet delivery path
US7697568B1 (en) * 2003-03-03 2010-04-13 Cisco Technology, Inc. Method and system for automatic modem bandwidth detection in a router
US20110040864A1 (en) * 2003-08-01 2011-02-17 Gray Eric W Systems and methods for inferring services on a network
US20080189353A1 (en) * 2003-08-01 2008-08-07 Gray Eric W Systems and methods for inferring services on a network
US8400941B2 (en) * 2003-08-01 2013-03-19 Eric W. Gray Systems and methods for inferring services on a network
US20100232445A1 (en) * 2003-12-19 2010-09-16 At & T Corporation Routing protocols with predicted outage notification
US20050135231A1 (en) * 2003-12-19 2005-06-23 At&T Corporation Routing protocols with predicted outage notification
US7907517B2 (en) 2003-12-19 2011-03-15 At&T Intellectual Property Ii, L.P. Routing protocols with predicted outage notification
US7756008B2 (en) * 2003-12-19 2010-07-13 At&T Intellectual Property Ii, L.P. Routing protocols with predicted outrage notification
US20050198262A1 (en) * 2004-01-14 2005-09-08 Jon Barry Method and system for measuring remote-access VPN quality of service
US20050286538A1 (en) * 2004-06-29 2005-12-29 Alcatel Method and call server for establishing a bi-directional peer-to-peer communication link
US20060008535A1 (en) * 2004-07-09 2006-01-12 Robert Sabin Anti tumor compositions and methods of use
US7449196B2 (en) 2004-07-09 2008-11-11 Robert Sabin Anti tumor compositions and methods of use
US8438117B2 (en) 2004-12-22 2013-05-07 International Business Machines Corporation Method and system for managing service levels provided by service providers
US20060171509A1 (en) * 2004-12-22 2006-08-03 International Business Machines Corporation Method and system for managing service levels provided by service providers
US7555408B2 (en) 2004-12-22 2009-06-30 International Business Machines Corporation Qualifying means in method and system for managing service levels provided by service providers
US10917313B2 (en) 2004-12-22 2021-02-09 International Business Machines Corporation Managing service levels provided by service providers
US9749194B2 (en) 2004-12-22 2017-08-29 International Business Machines Corporation Managing service levels provided by service providers
US7228255B2 (en) 2004-12-22 2007-06-05 International Business Machines Corporation Adjudication means in method and system for managing service levels provided by service providers
US7656886B2 (en) * 2005-02-07 2010-02-02 Chin-Tau Lea Non-blocking internet backbone network
US20060176809A1 (en) * 2005-02-07 2006-08-10 Hong Kong University Of Science And Technology Non-blocking internet backbone network
US7633876B2 (en) 2005-08-22 2009-12-15 At&T Intellectual Property I, L.P. System and method for monitoring a switched metro ethernet network
US20070041329A1 (en) * 2005-08-22 2007-02-22 Sbc Knowledge Ventures, L.P. System and method for monitoring a switched metro ethernet network
US20070076615A1 (en) * 2005-10-03 2007-04-05 The Hong Kong University Of Science And Technology Non-Blocking Destination-Based Routing Networks
US7898957B2 (en) 2005-10-03 2011-03-01 The Hong Kong University Of Science And Technology Non-blocking destination-based routing networks
US20070268882A1 (en) * 2006-05-22 2007-11-22 Lee Breslau Method for implementing and reporting one-way network measurements
US7953020B2 (en) * 2006-05-22 2011-05-31 At&T Intellectual Property Ii, L.P. Method for implementing and reporting one-way network measurements
US20080081051A1 (en) * 2006-09-28 2008-04-03 Robert Sabin Method of manufacturing anti-tumor and anti-viral compositions
US7848246B2 (en) * 2006-10-19 2010-12-07 Electronics And Telecommunications Research Institute Method and system for confirming connection of layer-1 label switched path(L1-LSP) in GMPLS-based network
US20080095171A1 (en) * 2006-10-19 2008-04-24 Electronics And Telecommunications Research Institute Method and system for confirming connection of layer-1 label switched path(L1-LSP) in GMPLS-based network
US7848337B1 (en) * 2006-11-14 2010-12-07 Cisco Technology, Inc. Auto probing endpoints for performance and fault management
US8451745B2 (en) * 2006-11-14 2013-05-28 Cisco Technology, Inc. Auto probing endpoints for performance and fault management
US20110063992A1 (en) * 2006-11-14 2011-03-17 Cisco Technology, Inc. Auto probing endpoints for performance and fault management
US8335162B2 (en) * 2007-08-13 2012-12-18 At&T Intellectual Property I, Lp Methods and apparatus to control traffic in a packet-switched network
US8699348B2 (en) 2007-08-13 2014-04-15 At&T Intellectual Property, I, L.P. Methods and apparatus to control traffic in a packet-switched network
US20090046583A1 (en) * 2007-08-13 2009-02-19 Henry Towster Methods and apparatus to control traffic in a packet-switched network
US8565104B2 (en) * 2007-08-31 2013-10-22 Yokogawa Electric Corporation Field control system and field control method
US20090105850A1 (en) * 2007-08-31 2009-04-23 Yokogawa Electric Corporation Field control system and field control method
US20100036810A1 (en) * 2008-08-08 2010-02-11 Oracle International Corporation Automated topology-based statistics monitoring and performance analysis
US8095507B2 (en) * 2008-08-08 2012-01-10 Oracle International Corporation Automated topology-based statistics monitoring and performance analysis
US8504522B2 (en) 2008-08-08 2013-08-06 Oracle International Corporation Automated topology-based statistics monitoring and performance analysis
WO2015034564A1 (en) * 2013-09-06 2015-03-12 Nec Laboratories America, Inc. Patent latency monitoring in software-defined networks

Also Published As

Publication number Publication date
WO2001047190A1 (en) 2001-06-28
US6366563B1 (en) 2002-04-02
AU2595401A (en) 2001-07-03

Similar Documents

Publication Publication Date Title
US6366563B1 (en) Method, computer program product, and apparatus for collecting service level agreement statistics in a communication network
US6363053B1 (en) Method and apparatus for measurement-based conformance testing of service level agreements in networks
Iannaccone et al. Analysis of link failures in an IP backbone
US7738396B1 (en) Network device having accounting service card
US7869352B1 (en) Adaptive network router
US7978627B2 (en) Systems and methods to monitor communications to identify a communications problem
US7254114B1 (en) Network router having integrated flow accounting and packet interception
US7813338B2 (en) System and method for analyzing asynchronous transfer mode communications
US7986632B2 (en) Proactive network analysis system
US7483379B2 (en) Passive network monitoring system
US20080159287A1 (en) EFFICIENT PERFORMANCE MONITORING USING IPv6 CAPABILITIES
CN100382517C (en) Network QoS test method and system
EP3202094B1 (en) Sampling packets to measure network performance
US7610327B2 (en) Method of automatically baselining business bandwidth
US7391739B1 (en) System and method for creating a frame relay port mirror
CN116346634A (en) State sensing information processing method and device of network management and control system and electronic equipment
Cisco Monitoring VPN Performance
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
Cisco Overview of TrafficDirector
US7180865B1 (en) System and method for analyzing frame relay communications
Damanik Securing Data Network for Growing Business Vpn Architectures Cellular Network Connectivity
Ruotsalainen L3 Latency in Regional Networks: Preparing 5G launch
JP4277067B2 (en) Network measurement information collection method, server device, and node device
JP4025592B2 (en) Network traffic management system

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION

AS Assignment

Owner name: WORLDCOM, INC., MISSISSIPPI

Free format text: CHANGE OF NAME;ASSIGNOR:MCI WORLDCOM, INC.;REEL/FRAME:032635/0148

Effective date: 20000501

Owner name: MCI LLC, VIRGINIA

Free format text: MERGER;ASSIGNOR:MCI INC.;REEL/FRAME:032635/0179

Effective date: 20060106

Owner name: VERIZON BUSINESS GLOBAL LLC, VIRGINIA

Free format text: CHANGE OF NAME;ASSIGNOR:MCI LLC;REEL/FRAME:032635/0201

Effective date: 20061120

Owner name: MCI, INC., VIRGINIA

Free format text: MERGER;ASSIGNOR:WORLDCOM, INC.;REEL/FRAME:032634/0342

Effective date: 20040420

AS Assignment

Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:VERIZON BUSINESS GLOBAL LLC;REEL/FRAME:032734/0502

Effective date: 20140409

AS Assignment

Owner name: MCI WORLDCOM, INC., MISSISSIPPI

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WELDON, PATRICK J;OSBORNE, JOSHUA;REEL/FRAME:036505/0112

Effective date: 20000105

AS Assignment

Owner name: VERIZON PATENT AND LICENSING INC., NEW JERSEY

Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE PREVIOUSLY RECORDED AT REEL: 032734 FRAME: 0502. ASSIGNOR(S) HEREBY CONFIRMS THE ASSIGNMENT;ASSIGNOR:VERIZON BUSINESS GLOBAL LLC;REEL/FRAME:044626/0088

Effective date: 20140409