US20170187603A1

US20170187603A1 - Application visibility in layer 3 networks

Info

Publication number: US20170187603A1
Application number: US15/457,317
Authority: US
Inventors: Jainendra Kumar; Raghu Ram Reddy Mavillapally
Original assignee: Juniper Networks Inc
Current assignee: Juniper Networks Inc
Priority date: 2014-06-26
Filing date: 2017-03-13
Publication date: 2017-06-29
Also published as: US9596164B1

Abstract

A device may receive configuration information for generating an application probe. The application probe may be used to request network information, associated with an application, from network devices. The device may determine, based on the configuration information, traffic parameters associated with the application. The device may determine a requested type of network information to be requested from the network devices. The device may generate the application probe by including, in the application probe, the traffic parameters and information identifying the requested type of network information. The device may transmit the application probe to a network device of the network devices. The device may receive, from the network device and based on transmitting the application probe, a value associated with the requested type of network information.

Description

BACKGROUND

In computer networks, network management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance, and provisioning of networked systems. Network management may be used to control a manner in which network traffic is processed by network devices included in a network.

SUMMARY

According to some possible implementations, a device may receive configuration information for generating an application probe. The application probe may be used to request network information, associated with an application, from network devices. The device may determine, based on the configuration information, traffic parameters associated with the application. The device may determine a requested type of network information to be requested from the network devices. The device may generate the application probe by including, in the application probe, the traffic parameters and information identifying the requested type of network information. The device may transmit the application probe to a network device of the network devices. The device may receive, from the network device and based on transmitting the application probe, a value associated with the requested type of network information.
According to some possible implementations, a computer-readable medium may store instructions that, when executed by a processor, cause the processor to receive configuration information for generating an application probe. The application probe may be used to request network information, associated with an application, from network devices. The instructions may cause the processor to determine, based on the configuration information, traffic parameters that identify a traffic flow associated with the application. The instructions may cause the processor to determine a type of network information to be requested from the network devices. The type of network information may be associated with processing of the application probe by the network devices. The instructions may cause the processor to generate the application probe. The application probe may include the traffic parameters and information identifying the type of network information. The instructions may cause the processor to transmit the application probe to a network device of the network devices. The instructions may cause the processor to receive, from the network device and based on transmitting the application probe, a value corresponding to the type of network information. The instructions may cause the processor to store the value corresponding to the type of network information.
According to some possible implementations, a method may include receiving, by a probing device, configuration information for generating application probes. The application probes may be used to request network information, associated with an application, from network devices. The method may include determining, by the probing device and based on the configuration information, a traffic parameter associated with the application. The method may include determining, by the probing device, a network information type to be requested from the network devices. The method may include generating, by the probing device, the application probes. The application probes may identify the traffic parameter and the network information type. The method may include transmitting, by the probing device, a first application probe, of the application probes, to a first network device of the network devices. The method may include transmitting, by the probing device, a second application probe, of the application probes, to a second network device of the network devices. The method may include receiving, by the probing device and from the first network device, a first value associated with the network information type. The method may include receiving, by the probing device and from the second network device, a second value associated with the network information type. The method may include storing, by the probing device, the first value and the second value.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an overview of an example implementation described herein:

FIG. 2 is a diagram of an example environment in which systems and/or methods, described herein, may be implemented;

FIG. 3 is a diagram of example components of one or more devices of FIG. 2;

FIG. 4 is a flow chart of an example process for generating application probes for requesting network information associated with an application;

FIGS. 5A and 5B are diagrams of an example implementation relating to the example process shown in FIG. 4;

FIG. 6 is a flow chart of an example process for gathering network information, associated with an application, using application probes; and

FIGS. 7A and 7B are diagrams of an example implementation relating to the example process shown in FIG. 6.

DETAILED DESCRIPTION

The following detailed description of example implementations refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.
An application provider that provides an application (e.g., a software application, a web application, etc.) may want to monitor attributes of network traffic, associated with the application, as the network traffic is communicated over a network. However, when the network traffic is communicated over the network (e.g., a layer 3 network), information that links the application to the network traffic may be lost. This may make it difficult to link attributes of the network traffic to the application. Implementations described herein assist in monitoring attributes of network traffic associated with an application (e.g., so that an application provider may improve performance of the application).
FIG. 1 is a diagram of an overview of an example implementation 100 described herein. As shown in FIG. 1, a probing device (e.g., a server, a gateway, a switch, etc.) may generate application probes for requesting network information associated with an application. An application probe may simulate behavior of an application packet that carries application information. An application probe may further indicate network information that the probing device is requesting from network devices that receive the application probe.
As further shown in FIG. 1, the probing device may transmit the application probes via a network, and network devices (e.g., routers, switches, gateways, etc.), included in the network, may receive the application probes. An application probe may store information that indicates a lifetime of the application probe, and when the lifetime expires, a particular network device that detects expiration of the application probe may read the requested network information, may determine a value associated with the requested network information (e.g., a value of the network information for the particular network device), and may provide the value back to the probing device. The probing device may provide values, received from multiple network devices, to an application device (e.g., a web server, a user device, etc.), and the application device may use the values to manage the application. In this way, an application provider may receive accurate network information for network traffic associated with an application, and may use the network information to modify performance of the application.
FIG. 2 is a diagram of an example environment 200 in which systems and/or methods, described herein, may be implemented. As shown in FIG. 2, environment 200 may include an application environment 210, which may include an application device 220. As further shown in FIG. 2, environment 200 may include a probing device 230, a set of network devices 240-1 through 240-N (N≧1) (hereinafter referred to collectively as “network devices 240,” and individually as “network device 240”), and a network 250. Devices of environment 200 may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.
Application environment 210 may include an environment associated with an application (e.g., a software application, a web application, etc.). Application environment 210 may include one or more hardware devices (e.g., application device 220) that assist in providing and/or managing the application. As an example, application environment 210 may include a data center, a cloud computing environment, a server farm, a server cluster, a private network, etc.
Application device 220 may include one or more devices capable of requesting, receiving, generating, storing, processing, and/or providing network information associated with an application. In some implementations, application device 220 may include a device associated with providing and/or managing an application (e.g., and/or may be located within application environment 210). For example, application device 220 may include a server device (e.g., a web server, an orchestration server, a management server, etc.) or a similar type of device. Additionally, or alternatively, application device 220 may include a device associated with receiving a service provided by an application (e.g., and/or may not be located within application environment 210). For example, application device 220 may include a desktop computer, a laptop computer, a mobile phone (e.g., a smart phone), or the like.
Probing device 230 may include one or more devices capable of generating, storing, processing, and/or transmitting application probes and/or information associated with application probes. For example, probing device 230 may include a server device (e.g., a proxy server, a monitoring server, etc.), a router, a switch, a gateway, a hub, a bridge, a security device (e.g., an intrusion detection device, a firewall, etc.), a load balancing device, or the like. In some implementations, probing device 230 may generate and transmit, to network device(s) 240, application probes for monitoring network traffic associated with an application, and may receive values, for the requested network information, from network device(s) 240.
In some implementations, probing device 230 may be located internal to application environment 210. In some implementations, probing device 230 may be located external to application environment 210 (e.g., within a particular quantity of hops). In some implementations, probing device 230 may be located on a border between application environment 210 and an external network (e.g., network 250).
Network device 240 may include one or more devices (e.g., one or more traffic transfer devices) capable of processing and/or transferring traffic between endpoint devices (e.g., application device 220 that provides an application and a user device that receives a service provided by the application). For example, network device 240 may include a router, a gateway, a switch, a hub, a bridge, a reverse proxy, a firewall, a server (e.g., a proxy server), a security device, an intrusion detection device, a load balancer, or a similar type of device. Network device 240 may receive an application probe from probing device 230 (and/or via one or more other network devices 240), may determine network information requested via the application probe, and may provide the requested network information to probing device 230.
Network 250 may include one or more wired and/or wireless networks. For example, network 250 may include a cellular network, a public land mobile network (PLMN), a wireless local area network (e.g., a Wi-Fi network), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber optic-based network, a cloud computing network, and/or a combination of these or another type of network.
The number and arrangement of devices and networks shown in FIG. 2 is provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in FIG. 2. Furthermore, two or more devices shown in FIG. 2 may be implemented within a single device, or a single device shown in FIG. 2 may be implemented as multiple, distributed devices. Additionally, or alternatively, a set of devices (e.g., one or more devices) of environment 200 may perform one or more functions described as being performed by another set of devices of environment 200.
FIG. 3 is a diagram of example components of a device 300. Device 300 may correspond to application device 220, probing device 230, and/or network device 240. In some implementations, application device 220, probing device 230, and/or network device 240 may include one or more devices 300 and/or one or more components of device 300. As shown in FIG. 3, device 300 may include a bus 310, a processor 320, a memory 330, a storage component 340, an input component 350, an output component 360, and a communication interface 370.
Bus 310 may include a component that permits communication among the components of device 300. Processor 320 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that interprets and/or executes instructions. Memory 330 may include a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, an optical memory, etc.) that stores information and/or instructions for use by processor 320.
Storage component 340 may store information and/or software related to the operation and use of device 300. For example, storage component 340 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, etc.), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and/or another type of computer-readable medium, along with a corresponding drive.
Input component 350 may include a component that permits device 300 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, etc.). Additionally, or alternatively, input component 350 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output component 360 may include a component that provides output information from device 300 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.).
Communication interface 370 may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables device 300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 370 may permit device 300 to receive information from another device and/or provide information to another device. For example, communication interface 370 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, or the like.
Device 300 may perform one or more processes described herein. Device 300 may perform these processes in response to processor 320 executing software instructions stored by a computer-readable medium, such as memory 330 and/or storage component 340. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.
Software instructions may be read into memory 330 and/or storage component 340 from another computer-readable medium or from another device via communication interface 370. When executed, software instructions stored in memory 330 and/or storage component 340 may cause processor 320 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
The number and arrangement of components shown in FIG. 3 is provided as an example. In practice, device 300 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 3. Additionally, or alternatively, a set of components (e.g., one or more components) of device 300 may perform one or more functions described as being performed by another set of components of device 300.
FIG. 4 is a flow chart of an example process 400 for generating application probes for requesting network information associated with an application. In some implementations, one or more process blocks of FIG. 4 may be performed by probing device 230. In some implementations, one or more process blocks of FIG. 4 may be performed by another device or a group of devices separate from or including probing device 230, such as application device 220 and/or network device 240.
As shown in FIG. 4, process 400 may include receiving configuration information for generating an application probe for requesting network information associated with an application (block 410). For example, probing device 230 may receive configuration information (e.g., via user input and/or input received from another device). As an example, a user may interact with an input device (e.g., a desktop computer, a laptop computer, etc.) to provide configuration information to probing device 230. In some implementations, probing device 230 may receive the configuration information via an application programming interface (API) that specifies configuration information and/or a format for configuration information to be provided to probing device 230. Probing device 230 may use the configuration information to generate one or more application probes for requesting network information associated with an application (e.g., a software application, a web application, an application associated with a provided service, etc.).
The configuration information may include, for example, an application identifier that includes one or more traffic parameters for identifying the application as being associated with a packet. For example, an application identifier may include a source network address (e.g., a media access control (MAC) address, an internet protocol (IP) address, a device identifier, etc.) associated with the application (e.g., a source network address that identifies a device that provides the application, such as application device 220), a destination network address associated with the application (e.g., that identifies a destination device to receive application information), a port identifier associated with the application (e.g., a source port identifier, a destination port identifier, etc.), a protocol identifier associated with the application (e.g., information that identifies a protocol via which application information is transmitted, such as transport control protocol (TCP), user datagram protocol (UDP), SIGTRAN protocol, a web traffic frame, an encrypted web traffic frame, etc.), or the like. In some implementations, the application identifier may include information that identifies a traffic flow via which application packets are carried. Additionally, or alternatively, the application identifier may include information associated with a tunnel via which application packets are carried (e.g., a tunnel identifier, tunnel endpoint identifiers, a type of tunnel, a protocol for the tunnel, etc.).
Additionally, or alternatively, the configuration information may include monitoring information that identifies a manner in which probing device 230 is to monitor network information associated with the application. For example, the monitoring information may indicate a start time for monitoring the network information (e.g., a start time at which application probes are to be transmitted to network devices 240), an end time for monitoring the network information (e.g., an end time at which probing device 230 is to stop transmitting application probes), a time period during which probing device 230 is to monitor the network information, a quantity of network devices 240 from which to request network information (e.g., a quantity of hops to which application probes are to be sent), etc.
The configuration information may identify a type of network information to be requested from network devices 240, in some implementations. Network information may include information associated with network traffic being processed by network device 240. Additionally, or alternatively, network information may include information associated with processing the application probe (e.g., by network device 240). For example, network information may include a measure of bandwidth utilization of network device 240 (e.g., an average bandwidth utilization for all network traffic, a bandwidth utilization on a particular interface via which the application probe is input and/or output, etc.), a measure of central processing unit (CPU) utilization of network device 240, a quantity of network traffic being processed by network device 240, a measure of latency associated with network traffic and/or an application probe processed by network device 240 (e.g., an average latency, a maximum latency, a minimum latency, a switching latency, etc.), a measure of jitter associated with the network traffic, a packet drop rate associated with the network traffic and/or the application probe, a queue utilization of network device 240, information that identifies a path for the network traffic and/or the application probe (e.g., a path through one or more network devices 240, such as an equal-cost multi-path (ECMP) routing path), load balancing information (e.g., an ECMP bucket utilization for detecting fair load balancing), a click synchronization protocol used by network device 240 (e.g., a precision time protocol (PTP), etc.), etc.
In some implementations, the configuration information may identify a set (e.g., one or more) of the above types of network information, or other types of network information, to be requested from network devices 240. Additionally, or alternatively, the user may use a group identifier to select a set of network information types, and the group identifier may be provided to probing device 230. Probing device 230 may use the group identifier to identify the set of network information types to be requested. For example, the user may provide an indication to collect information associated with a traffic flow (e.g., application-centric information), information associated with an overlay, such as a tunnel (e.g., application overlay information), etc.
As further shown in FIG. 4, process 400 may include generating the application probe based on the configuration information (block 420). For example, probing device 230 may generate the application probe using the configuration information. The application probe may include a packet that identifies an application (e.g., using an application identifier, application parameters, etc., as described above) and/or that identifies network information to be returned by one or more network devices 240 that receive the application probe.
For example, probing device 230 may include, in a payload of the packet, an application probing header that indicates that network information is to be returned by network device 240, and/or that identifies a type of network information to be returned. In some implementations, probing device 230 may generate the application probe using a protocol specified in the configuration information (e.g., a same protocol as application packets). Additionally, or alternatively, probing device 230 may generate the application probe by encapsulating the payload (e.g., using IP encapsulation and/or application-level encapsulation).
In some implementations, probing device 230 may insert expiration information in the application probe. Network device 240 may use the expiration information to determine whether to provide the requested network information. For example, if the expiration information indicates that the application probe (e.g., a packet) expires upon being received by a particular network device 240, then the particular network device 240 may detect this expiration, and may provide the requested network information. The expiration information may identify an expiration condition that causes the application probe to expire (e.g., a particular amount of time after which the application probe expires, a particular quantity of hops after which the application probe expires, etc.).
In some implementations, the expiration information may include a time-to-live (TTL) indicator. The TTL indicator may indicate a time period for application probe expiration, and/or may indicate a quantity of hops after which the application probe expires. Probing device 230 may generate multiple application probes for a particular application, and different application probes may have different TTL indicators. For example, probing device 230 may generate a first application probe with a TTL indicator of one, indicating that the application probe expires upon reaching a first network device 240 that is one hop away from probing device 230. Similarly, probing device 230 may generate a second application probe with a TTL indicator of two, indicating that the application probe expires upon reaching a second network device 240 that is two hops away from probing device 230. In this way, probing device 230 may gather end-to-end network information from multiple network devices 240.
As further shown in FIG. 4, process 400 may include transmitting the application probe to one or more network devices (block 430). For example, probing device 230 may transmit each generated network probe via a network (e.g., network 250). The application probes may be received by network device(s) 240, which may provide requested network information upon detecting expiration of the application probe, as described in more detail elsewhere herein. In some implementations, probing device 230 may periodically transmit a set of application probes. Additionally, or alternatively, probing device 230 may transmit the set of application probes based on configuration information (e.g., monitoring information that indicates when to transmit application probes, how many application probes to transmit, etc.). In some implementations, probing device 230 may encrypt the application probes.
In this way, probing device 230 may use simulated application packets, in the form of application probes, to collect network information that indicates a manner in which actual application packets (e.g., that carry application information) are processed in a network (e.g., by network devices 240). Thus, probing device 230 may collect network information relating to an application layer (e.g., layer 4) using application probes in a network layer (e.g., layer 3).
Although FIG. 4 shows example blocks of process 400, in some implementations, process 400 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in FIG. 4. Additionally, or alternatively, two or more of the blocks of process 400 may be performed in parallel.
FIGS. 5A and 5B are diagrams of an example implementation 500 relating to example process 400 shown in FIG. 4. FIGS. 5A and 5B show an example of generating application probes for requesting network information associated with an application.
As shown in FIG. 5A, and by reference number 510, assume that a user (e.g., an application administrator) interacts with an input device (e.g., a desktop computer, a laptop computer, etc.) to input configuration information using a probing device API. For example, assume that the user inputs traffic parameters for identifying an application to be monitored. As shown, assume that the application is identified using a source IP address of 192.26.8.4, a source port of 80, a destination IP address of 172.16.254.1, a destination port of 80, and a protocol of TCP. As further shown, assume that network information is to be monitored from 2 hops, and that the requested network information is to include application-centric information (e.g., which may act as a group identifier associated with one or more network information types to be requested from network device 240). As shown by reference number 520, assume that the input device provides the configuration information to probing device 230.
As shown in FIG. 5B, and by reference number 530, assume that probing device 230 generates application probes based on the configuration information. For example, assume that probing device 230 generates two application probes, shown as Probe 1 and Probe 2, to return network information from each of the 2 hops indicated in the configuration information. Further, assume that each application probe includes an application identifier based on the traffic parameters included in the configuration information, includes a different TTL indicator based on the number of hops to be monitored, and includes an application probing header that identifies requested network information types. In this case, assume that application-centric information, to be requested from network devices 240, includes a measure of latency at each hop (e.g., each network device 240), an application flow path at each hop, and a measure of bandwidth utilization at each hop.
As shown by reference number 540, assume that probing device 230 transmits the application probes over a network. As shown by reference number 550, since Probe 1 has a TTL indicator of one (e.g., will expire at the first hop reached), a first network device 240, shown as Network Device 1, may receive Probe 1 and send the requested network information back to probing device 230, as described in more detail elsewhere herein. As shown by reference number 560, since Probe 2 has a TTL indicator of two (e.g., will expire at the second hop reached). Network Device 1 may transmit Probe 2 to a second network device 240, shown as Network Device 2. Network device 2 may receive Probe 2, and may send the requested network information back to probing device 230, as described in more detail elsewhere herein.
Since the application probes include an application identifier for the application to be monitored (e.g., since an application probe simulates an application packet), network devices 240 may process the application probes as if the application probes were actual application packets that carry application information. In this way, probing device 230 may gather network information that indicates a manner in which actual application packets are processed in a network (e.g., a layer 3 network).
As indicated above. FIGS. 5A and 5B are provided merely as an example. Other examples are possible and may differ from what was described with regard to FIGS. 5A and 5B.
FIG. 6 is a flow chart of an example process 600 for gathering network information, associated with an application, using application probes. In some implementations, one or more process blocks of FIG. 6 may be performed by network device 240 and/or probing device 230. In some implementations, one or more process blocks of FIG. 6 may be performed by another device or a group of devices separate from or including network device 240 and/or probing device 230, such as application device 220.
As shown in FIG. 6, process 600 may include receiving an application probe and detecting probe expiration (block 610). For example, network device 240 may receive an application probe (e.g., from probing device 230 and/or from another network device 240). Network device 240 may determine whether the application probe has expired. For example, network device 240 may read expiration information from the application probe to determine whether the application probe has expired. In some implementations, network device 240 may determine whether a TTL indicator indicates application probe expiration. If the TTL indicator indicates application probe expiration, then network device 240 may detect the application probe expiration. If the TTL indicator does not indicate application probe expiration, then network device 240 may reduce the TTL indicator (e.g., by decrementing a TTL counter), and may transmit the application probe to a next network device 240 in a routing path.
As further shown in FIG. 6, process 600 may include determining network information requested via the application probe (block 620). For example, when network device 240 detects application probe expiration, then network device 240 may determine network information requested via the application probe. Network device 240 may read the application probe (e.g., a payload of the application probe) to identify one or more types of network information requested by probing device 230. Network device 240 may determine values for each type of requested network information, and may include the values in a return packet to be provided to probing device 230. In some implementations, network device 240 may retrieve the values (e.g., from a data structure stored locally by network device 240, from a data structure stored remotely from network device 240 but accessible by network device 240, etc.).
As further shown in FIG. 6, process 600 may include providing the requested network information (block 630). For example, network device 240 may insert the requested network information in a return packet, and may transmit the return packet to probing device 230. In some implementations, network device 240 may include the requested network information (e.g., values for the types of requested network information) in a payload of the return packet. Additionally, or alternatively, network device 240 may encapsulate the payload using an Internet Control Message Protocol (ICMP) header that includes, for example, the application identifier (e.g., determined by reading the application probe), a device identifier for network device 240 (e.g., a network address that identifies network device 240 as a source of the requested network information), a device identifier for probing device 230 (e.g., a network address that identifies probing device 230 as a destination for the requested network information), etc. Additionally, or alternatively, network device 240 may encapsulate the ICMP header using an IP header. Additionally, or alternatively, network device 240 may include a TTL indicator in the return packet such that the return packet expires when the return packet arrives at probing device 230.
As further shown in FIG. 6, process 600 may include receiving the requested network information (block 640). For example, probing device 230 may receive the return packet, from network device 240, and may read the requested network information (e.g., the value(s) for the network information type(s)) from the return packet.
As further shown in FIG. 6, process 600 may include aggregating network information received in association with multiple application probes (block 650), and providing the network information and/or the aggregated network information (block 660). For example, probing device 230 may provide the received network information (e.g., the received values) to application device 220. In some implementations, probing device 230 may provide information that identifies an application with which the network information is associated (e.g., based on an application identifier included in the return packet and/or stored by probing device 230). In this case, application device 220 may process and/or aggregate the network information to modify one or more characteristics of the application (e.g., to improve application performance). In some implementations, application device 220 may request network information from probing device 230 using an API. For example, application device 220 may provide an application identifier, and probing device 230 may return network information associated with the application identifier.
Additionally, or alternatively, probing device 230 may aggregate network information associated with multiple application probes, and may provide the aggregated network information to application device 220. For example, probing device 230 may aggregate network information, associated with a particular application, received from multiple network devices 240. Additionally, or alternatively, probing device 230 may perform a calculation using network information received from multiple network devices 240, to determine an end-to-end treatment of application packets. For example, probing device 230 may determine an average value (e.g., an average latency across multiple network devices 240, an average bandwidth utilization, etc.), may determine a maximum value (e.g., a maximum value of a particular type of network information), may determine a minimum value (e.g., a minimum value of a particular type of network information), or the like.
In this way, application device 220 may use the aggregated network information to improve application performance. For example, application device 220 may use the network information to execute (e.g., launch) an application in an intelligent manner, may use the network information to improve performance of an application that is already executing, etc.
Although FIG. 6 shows example blocks of process 600, in some implementations, process 600 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in FIG. 6. Additionally, or alternatively, two or more of the blocks of process 600 may be performed in parallel.
FIGS. 7A and 7B are diagrams of an example implementation 700 relating to example process 600 shown in FIG. 6. FIGS. 7A and 7B show an example of gathering network information, associated with an application, using application probes. For the purpose of FIGS. 7A and 7B, assume that the operations described herein with respect to FIGS. 5A and 5B have been performed.
As shown in FIG. 7A, and by reference number 710, assume that Network Device 1 retrieves (e.g., from a data structure) the information requested by Probe 1. For example, assume that Network Device 1 determines that the Probe 1 is associated with a latency of 200 milliseconds (ms), an application flow path that includes Network Device 1 and Network Device 2, and a bandwidth utilization of 60%. As shown by reference number 720, assume that Network Device 2 retrieves the information requested by Probe 2. For example, assume that Network Device 2 determines that the Probe 2 is associated with a latency of 500 ms, an application flow path that includes Network Device 2 and Network Device 3 (not shown), and a bandwidth utilization of 98%. As shown by reference number 730, assume that Network Device 1 and Network Device 2 each encapsulate this requested network information in return packets, and provide the returns packet to probing device 230.
As shown in FIG. 7B, and by reference number 740, assume that probing device 230 aggregates the received network information. For example, probing device 230 may aggregate the network information by storing a relationship between the application identifier and the network information received from each network device 240 (e.g., Network Device 1 and Network Device 2). As another example, probing device 230 may aggregate the network information by performing one or more calculations, and storing a relationship between the application identifier and a result of the calculation(s). For example, and as shown, assume that probing device 230 determines an average per hop latency (e.g., 350 ms), an aggregate application flow path (e.g., that includes Network Device 1, Network Device 2, and Network Device 3), and an average bandwidth utilization (e.g., 79%). Furthermore, assume that probing device 230 identifies Network Device 2 as a problematic network device 240 (e.g., based on one or more values of requested network information satisfying one or more thresholds).
As shown by reference number 750, assume that probing device 230 provides the network information and/or the aggregated network information to application device 220. As shown by reference number 760, assume that application device 220 modifies delivery of the application based on the received network information. In this way, application device 220 may use network information, relating to a manner in which application packets are processed by network devices 240, to manage an application.
As indicated above, FIGS. 7A and 7B are provided merely as an example. Other examples are possible and may differ from what was described with regard to FIGS. 7A and 7B.
Implementations described herein assist in monitoring attributes of network traffic associated with an application (e.g., so that an application provider may improve performance of the application).
The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the implementations.
As used herein, the term component is intended to be broadly construed as hardware, firmware, and/or a combination of hardware and software.
As used herein, a packet may refer to a network packet, a frame, a datagram, a segment, a fragment of a packet, a fragment of a frame, a fragment of a datagram, a fragment of a segment, or any other formatted or unformatted unit of data capable of being transmitted via a network.
Some implementations are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, etc.
It will be apparent that systems and/or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and/or methods were described herein without reference to specific software code—it being understood that software and hardware can be designed to implement the systems and/or methods based on the description herein.
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.
No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items, and may be used interchangeably with “one or more.” Where only one item is intended, the term “one” or similar language is used. Also, as used herein, the terms “has.” “have,” “having.” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

Claims

1-20. (canceled)

21. A method comprising:

receiving, by a network device, an application probe;

determining, by the network device, that the application probe has expired;

determining, by the network device and based on determining that the application probe has expired, information requested via the application probe; and

providing, by the network device, the information requested via the application probe.

22. The method of claim 21, where the application probe comprises expiration information; and

where determining that the application probe has expired comprises:

determining that the application probe has expired based on reading the expiration information.

23. The method of claim 22, where the expiration information comprises a time-to-live (TTL) indicator, and

where determining that the application probe has expired comprises:

determining that the application probe has expired based on the TTL indicator.

24. The method of claim 21, where providing the information requested via the application probe comprises:

reading a payload of the application probe to identify the information requested via the application probe.

25. The method of claim 21, where the application probe comprises expiration information comprising an expiration condition,

the expiration condition indicating at least one of:

an amount of time after which the application probe expires, or

a quantity of hops after which the application probe expires.

26. The method of claim 21, where providing the information requested via the application probe comprises:

inserting the information, requested via the application probe, in a return packet,

the return packet comprising a time-to-live (TTL) indicator.

27. The method of claim 26, where the return packet comprises a payload; and

where inserting the information, requested via the application probe, in the return packet comprises:

encapsulating the payload using an Internet Control Message Protocol (ICMP) header,

the ICMP header including at least one of:

an application identifier,

a device identifier for the network device, or

a device identifier for a probing device.

28. A computer-readable medium storing instructions, the instructions comprising:

one or more instructions that, when executed by one or more processors of a network device, cause the one or more processors to:

receive an application probe;

determine that the application probe has expired;

determine, based on determining that the application probe has expired, information requested via the application probe; and

provide the information requested via the application probe.

29. The computer-readable medium of claim 28, where the application probe comprises expiration information; and

where the one or more instructions, that cause the one or more processors to determine that the application probe has expired, are to:

determine that the application probe has expired based on reading the expiration information.

30. The computer-readable medium of claim 29, where the expiration information comprises a time-to-live (TTL) indicator; and

determine that the application probe has expired based on the TTL indicator.

31. The computer-readable medium of claim 28, where the one or more instructions, that cause the one or more processors to provide the information requested via the application probe, are to:

read a payload of the application probe to identify the information requested via the application probe.

32. The computer-readable medium of claim 28, where the application probe comprises expiration information comprising an expiration condition,

the expiration condition indicating at least one of:

an amount of time after which the application probe expires, or

a quantity of hops after which the application probe expires.

33. The computer-readable medium of claim 28, where the one or more instructions, that cause the one or more processors to provide the information requested via the application probe, are to:

insert the information, requested via the application probe, in a return packet,

the return packet comprising a time-to-live (TTL) indicator.

34. The computer-readable medium of claim 33, where the return packet comprises a payload; and

where the one or more instructions, that cause the one or more processors to insert the information, requested via the application probe, in the return packet, are to:

encapsulate the payload using an Internet Control Message Protocol (ICMP) header,

the ICMP header including at least one of:

an application identifier,

a device identifier for the network device, or

a device identifier for a probing device.

35. A device, comprising:

one or more memories; and

one or more processors, communicatively coupled to the one or more memories, to:

receive an application probe;

determine that the application probe has expired;

provide the information requested via the application probe.

36. The device of claim 35, where the application probe comprises expiration information; and

where the one or more processors, when determining that the application probe has expired, are to:

37. The device of claim 36, where the expiration information comprises a time-to-live (TTL) indicator; and

determine that the application probe has expired based on the TTL indicator.

38. The device of claim 35, where the one or more processors, when providing the information requested via the application probe, are to:

39. The device of claim 35, where the application probe comprises expiration information comprising an expiration condition,

the expiration condition indicating at least one of:

an amount of time after which the application probe expires, or

a quantity of hops after which the application probe expires.

40. The device of claim 35,

where the one or more processors, when providing the information requested via the application probe, are to:

the return packet comprising a time-to-live (TTL) indicator;

where the return packet comprises a payload; and

where the one or more processors, when inserting the information, requested via the application probe, in the return packet, are to:

the ICMP header including at least one of:

an application identifier,

a device identifier for the device, or

a device identifier for a probing device.