Communications networks are generally packet-switched networks that operate based on Internet Protocol (IP). Packets from a source device may travel to a destination device via paths chosen by forwarding devices connecting them. Since the forwarding devices operate independently and generally make local forwarding decisions, the path between the source and destination devices may not be the same for each packet, and may not be the same in each direction. This presents a challenge to trace packets and their paths through different forwarding devices in the network.
In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. In the drawings, similar symbols typically identify similar components, unless context dictates otherwise. The illustrative embodiments described in the detailed description, drawings, and claims are not meant to be limiting. Other embodiments may be utilized, and other changes may be made, without departing from the spirit or scope of the subject matter presented here. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the drawings, can be arranged, substituted, combined, and designed in a wide variety of different configurations, all of which are explicitly contemplated herein.
Referring to the SDN controller device on the left-hand side of
Referring to the forwarding device on the right-hand side of
Unlike a conventional network, the SDN environment according to example process 100 allows logical separation between a control plane that decides how packets are forwarded, and a data plane that implements how packets are forwarded. The SDN controller device acts as the control plane and configures the forwarding devices, which act as the data plane, to generate trace information.
Since the trace information received from the forwarding devices includes both header information and payload information, the SDN controller device may generate aggregated trace information that provides a global view of how and which packets are forwarded in the SDN environment. For example, the aggregated trace information identifies forwarding devices that processed a particular packet, or packets processed by a particular forwarding device, or both. Each forwarding device may “process” a packet in any suitable manner, such as forwarding the packet to another forwarding device, forwarding the packet to the SDN controller device, forwarding the packet to a user or host in the user space, modifying the header information of the packet before forwarding it and dropping the packet, etc.
Using example process 100, the forwarding devices may be configured by the SDN controller device to generate trace information associated with any communication flow of interest. The aggregated trace information may then be used in any suitable application, such as network debugging, packet loss analysis and monitoring, network infrastructure health monitoring, network security monitoring, security policy compliance monitoring, and application network protocol analysis (e.g., Network File System (NFS)), etc.
SDN Environment
SDN controller device 210 represents the control plane that decides how packets are forwarded and what trace information to capture by forwarding devices 220 in SDN environment 200. SDN controller device 210 may also be responsible for other higher-level control functions, such as policy enforcement, security checks and naming, etc. Forwarding devices 220 represent the data plane that performs packet forwarding and generates trace information depending on configuration by SDN controller device 210.
Forwarding devices 220 each maintain a flow table 230 (e.g., Flow Table 1 at Forwarding Device 1, Flow Table 2 at Forwarding Device 2, etc.) that is configurable by SDN controller device 210. For example, SDN controller device 210 may instruct adding entries 240 to, or deleting entries 240 from, flow table 230 of forwarding device 220. Each entry 240 may include flow characteristic information 242 to be matched by forwarding device 220 against received packets, and action 244 to be performed once a match is found.
Any suitable flow characteristic information may be used to match a packet against a particular communication flow, such as fields from different protocol layers, etc. Examples include source and destination Internet Protocol (IP) addresses; source and destination Media Access Control (MAC) addresses; source and destination port numbers in a transport layer (e.g. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port numbers); and protocol (e.g., IPv4 or IPv6 protocol number), etc.
Action 244 specifies how forwarding device 220 handles or processes a packet that matches flow characteristic information 242. For example, action 244 may be to drop the packet, forward the packet to an outgoing port, forward the packet to SDN controller device 210 and generate trace information associated with a communication flow, etc. Forwarding device 220 may also modify header information of the packet before forwarding it to another device 220, SDN controller device 210 or a user (not shown for simplicity). In
Entries 240 in flow table 230 may each be associated with a “communication flow”, which may generally refer to a stream of packets between source device 250 and destination device 252. SDN controller device 210 decides whether a communication flow is permissible in SDN environment, such as according to network policy, etc. Although not shown in
Any suitable SDN protocol may be used by SDN controller device 210 to configure forwarding devices 220 in SDN environment 200, such as OpenFlow protocol (OFP); CLIs (Command-line Interfaces); NETCONF (Network Configuration Protocol); NETCONF (Yang Schema); SNMP (Simple Network Management Protocol); XMPP (Extensible Messaging and Presence Protocol); OpenStack; virtualization software APIs (Application Programming Interfaces); OF-Config (OpenFlow Management and Configuration Protocol); and Secure Shell (SSH), etc. SDN controller device 210 and forwarding devices 220 may communicate via a secure channel.
Packet Tracing Configuration
At block 310 (related to 110 in
At block 320 (related to 140 in
At block 310, SDN controller device 210 may also specify a trace duration in configuration information 312. In this case, forwarding device 220 will generate trace information during the trace duration and report to SDN controller device 210 after the trace duration elapses. The trace duration may be tracked by each forwarding device 220 using any suitable technique, such as setting a timer, etc. Setting the trace duration reduces the need for forwarding device 220 to report to SDN controller device 210 every time a packet is received, thereby reducing processing burden on forwarding device 220 and traffic in SDN environment 200.
At block 330 (related to 150 in
At block 340 (related to 160 in
It will be appreciated that header and payload information 346 in trace information 342 may be a copy of the corresponding header 334 and payload 336 information in packet 332. Alternatively, forwarding devices 220 may analyse packet 332 to generate an extract of the packet's header 334 and payload 336. Generating the extract, instead of an exact copy of packet 332, requires additional processing at forwarding device 220 but reduces the size of trace information 342 sent to SDN controller device 210.
At block 350 (related to 160 in
Trace information 342 from forwarding devices 220 may then be used by SDN controller device 210 to generate aggregated trace information according to blocks 120 and 130 in
Aggregated Trace Information
In the example in
To generate aggregated trace information 410, SDN controller device 210 compares trace information 342-1 to 342-N from Forwarding Devices 1 to N to identify, inter alia, forwarding devices 220 that processed a particular packet (e.g., Forwarding Devices 1 to N processed Packet 1), or different packets processed by a particular forwarding device 220 (e.g., Packets 1 to N are processed by Forwarding Device 1), or both.
For example, SDN controller device 210 may identify a particular packet (e.g., Packet 1) based on header and payload information from a particular device (e.g., 346-1 from Forwarding Device 1), which may then be mapped to header and payload information from another device (e.g., 346-2 from Forwarding Device 2). This process is repeated for other devices (e.g., Forwarding Devices 3 to N) to trace a path through which the same packet is forwarded.
Since header information of packet 332 may be updated by forwarding devices 220 as it is forwarded, its payload information generally provides a more accurate indication as to whether two packets (e.g., Packet 1-1 processed at Forwarding Device 1 and Packet N−1 processed at Forwarding Device N) are the same. For example, the checksum of Packet 1-1 may be compared against the checksum of Packet N−1 to verify whether they are the same packet.
Once a particular packet (e.g., Packet 1) is identified, SDN controller device 210 may determine which forwarding devices 220 (e.g., Forwarding Devices 1 to N) have processed that particular packet (e.g., Packet 1) based on device IDs (see 348-1 to 348-N). Further, based on direction (see 349-1 to 349-N), SDN controller device 210 may then determine which path the packet (e.g., Packet 1) is forwarded, and whether it is forwarded or dropped at different forwarding devices 220 along the path. For example, as indicated at 420, Packet 3 is forwarded along a path defined by Forwarding Devices 1 to N. Also, Packet 3 is forwarded by Forwarding Devices 1 to (N−1) before being dropped at Forwarding Device N.
Similarly, SDN controller device 210 may determine packets processed by a particular forwarding device 220 (e.g., Forwarding Device N) once different packets are identified. For example, as indicated at 430, based on header and payload information of different packets 346-1 to 346-N, SDN controller device 210 may determine that Forwarding Device N has processed Packet 1 to Packet M of Flow 1, including forwarding Packet 1 and Packet 2 but dropping Packet 3.
Computing Devices
The above examples can be implemented by hardware (including hardware logic circuitry), software or firmware or a combination thereof.
First computing device 510 may include processor 520 and memory 530 that may communicate with each other via a bus (not shown for simplicity), etc. Memory 530 stores instructions 532 which, in response to execution by processor 520, cause processor 520 to perform processes described herein with reference to
Second computing device 550 may include processor 560 and memory 570 that may communicate with each other via a bus (not shown for simplicity), etc. Memory 570 stores instructions 572 which, in response to execution by processor 560, cause processor 560 to perform processes described herein with reference to
Although not shown, first computing device 510 and second computing device 550 may each include multiple interfaces (e.g., outgoing ports and incoming ports) via which information is received or sent.
The techniques introduced above can be implemented in special-purpose hardwired circuitry, in software and/or firmware in conjunction with programmable circuitry, or in a combination thereof. Special-purpose hardwired circuitry may be in the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), and others. The term ‘processor’ is to be interpreted broadly to include a processing unit, ASIC, logic unit, or programmable gate array etc.
The foregoing detailed description has set forth various embodiments of the devices and/or processes via the use of block diagrams, flowcharts, and/or examples. Insofar as such block diagrams, flowcharts, and/or examples contain one or more functions and/or operations, it will be understood by those within the art that each function and/or operation within such block diagrams, flowcharts, or examples can be implemented, individually and/or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof.
Those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure.
Software and/or firmware to implement the techniques introduced here may be stored on a non-transitory machine-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A “machine-readable storage medium”, as the term is used herein, includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant (PDA), mobile device, manufacturing tool, any device with a set of one or more processors, etc.). For example, a machine-accessible storage medium includes recordable/non recordable media (e.g., read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.)
The drawings are only illustrations of an example, wherein the units or procedure shown in the drawings are not necessarily essential for implementing the present disclosure. Those skilled in the art will understand that the units in the device in the examples can be arranged in the device in the examples as described, or can be alternatively located in one or more devices different from that in the examples. The units in the examples described can be combined into one module or further divided into a plurality of sub-units.
It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.
The present application is a continuation application under 35 U.S.C. § 120 of U.S. patent application Ser. No. 14/226,851, filed on Mar. 27, 2014 and entitled “Packet tracing in a software-defined networking environment.” The aforementioned U.S. Patent Application, including any appendices or attachments thereof, is hereby incorporated by reference in its entirety.
Number | Name | Date | Kind |
---|---|---|---|
5224100 | Lee et al. | Jun 1993 | A |
5245609 | Ofek et al. | Sep 1993 | A |
5265092 | Soloway et al. | Nov 1993 | A |
5781534 | Pelman et al. | Jul 1998 | A |
6104700 | Haddock et al. | Aug 2000 | A |
6430160 | Smith et al. | Aug 2002 | B1 |
6721334 | Ketcham | Apr 2004 | B1 |
7079544 | Wakayama et al. | Jul 2006 | B2 |
7627692 | Pessi | Dec 2009 | B2 |
7706266 | Plamondon | Apr 2010 | B2 |
7760735 | Chen et al. | Jul 2010 | B1 |
7808919 | Nadeau et al. | Oct 2010 | B2 |
7937492 | Kompella et al. | May 2011 | B1 |
8345558 | Nicholson et al. | Jan 2013 | B2 |
8351418 | Zhao et al. | Jan 2013 | B2 |
8611351 | Gooch et al. | Dec 2013 | B2 |
9419874 | Sun | Aug 2016 | B2 |
20050132044 | Guingo et al. | Jun 2005 | A1 |
20050232230 | Nagami et al. | Oct 2005 | A1 |
20060028999 | Iakobashvilli et al. | Feb 2006 | A1 |
20060029056 | Perera et al. | Feb 2006 | A1 |
20060037075 | Frattura et al. | Feb 2006 | A1 |
20060206655 | Chappell et al. | Sep 2006 | A1 |
20060282895 | Rentzis et al. | Dec 2006 | A1 |
20070055789 | Claise et al. | Mar 2007 | A1 |
20080049614 | Briscoe et al. | Feb 2008 | A1 |
20080049786 | Ram et al. | Feb 2008 | A1 |
20080253299 | Damm et al. | Oct 2008 | A1 |
20090010254 | Shimada | Jan 2009 | A1 |
20100128623 | Dunn et al. | May 2010 | A1 |
20110317696 | Aldrin et al. | Dec 2011 | A1 |
20120159454 | Barham et al. | Jun 2012 | A1 |
20120287791 | Xi et al. | Nov 2012 | A1 |
20130058228 | Koponen | Mar 2013 | A1 |
20130067067 | Miri et al. | Mar 2013 | A1 |
20130242758 | Vaidya et al. | Sep 2013 | A1 |
20130332602 | Nakil et al. | Dec 2013 | A1 |
20140029451 | Nguyen | Jan 2014 | A1 |
20140119203 | Sundaram et al. | May 2014 | A1 |
20140195666 | Dumitriu et al. | Jul 2014 | A1 |
20140281030 | Cui et al. | Sep 2014 | A1 |
20150016298 | Ganichev | Jan 2015 | A1 |
20150103642 | Stuart | Apr 2015 | A1 |
20150256397 | Agarwal | Sep 2015 | A1 |
20150281036 | Sun et al. | Oct 2015 | A1 |
20150281076 | Zhang et al. | Oct 2015 | A1 |
Number | Date | Country |
---|---|---|
2002-141905 | May 2002 | JP |
WO 9506989 | Mar 1995 | WO |
WO 2013184846 | Dec 2013 | WO |
Entry |
---|
Nikhil Handigol et al., “Where is the Debugger for my Software-Defined Network?”, HotSDN'12, Aug. 13, 2012, ACM. |
U.S. Appl. No. 61/969,960, filed Mar. 25, 2014. |
Handigol, Nikhil, et al., “Where is the Debugger for my Software-Defined Network?”, HotSDN'12, Aug. 13, 2012, 6 pages, ACM, Helsinki, Finland. |
Phaal, Peter, et al., “sFlow Version 5”, Jul. 2004, 46 pages, available at http://www.sflow.org/sflow—version—5.txt. |
Phan, Doantam, et al., “Visual Analysis of Network Flow Data with Timelines and Event Plots”, Month Unknown, 2007, pp. 1-16, VizSEC. |
Zhang, Hui, et al. (U.S. Appl. No. 61/969,960), filed Mar. 25, 2014. |
Number | Date | Country | |
---|---|---|---|
20160380874 A1 | Dec 2016 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 14226851 | Mar 2014 | US |
Child | 15236471 | US |