Invented by Vyshakh Krishnan C H, Faseela K, Siva Kumar V V K A PERUMALLA, Telefonaktiebolaget LM Ericsson AB

The market for apparatus for tracing packets through a packet pipeline in a software-defined networking switch is experiencing significant growth due to the increasing demand for efficient network management and troubleshooting solutions. As software-defined networking (SDN) continues to gain traction in various industries, the need for advanced packet tracing capabilities becomes crucial for network administrators. In a traditional networking environment, packet tracing involves complex and time-consuming processes, often requiring manual intervention. However, with the advent of SDN, network administrators can now leverage innovative apparatus specifically designed for tracing packets through a packet pipeline in a software-defined networking switch. These apparatus offer a range of features and functionalities that simplify the packet tracing process, allowing network administrators to quickly identify and resolve network issues. By providing real-time visibility into the packet flow within the network, these apparatus enable administrators to monitor and analyze network traffic efficiently. One of the key drivers of the market growth is the increasing complexity of modern networks. As networks become more intricate and dynamic, it becomes challenging for administrators to identify the root cause of network issues. Apparatus for tracing packets through a packet pipeline in an SDN switch offer a comprehensive view of the network, allowing administrators to pinpoint bottlenecks, latency issues, or any other anomalies that may affect network performance. Moreover, these apparatus enable network administrators to troubleshoot network problems more effectively. By providing detailed information about packet routes, delays, and drops, administrators can quickly identify the source of the problem and take appropriate actions. This not only reduces network downtime but also enhances overall network performance. The market for apparatus for tracing packets through a packet pipeline in an SDN switch is also driven by the increasing adoption of cloud computing and virtualization technologies. As organizations migrate their infrastructure to the cloud and embrace virtualization, the need for efficient network management and troubleshooting solutions becomes paramount. These apparatus offer a seamless integration with cloud environments and virtual networks, providing administrators with a holistic view of the entire network infrastructure. Furthermore, the market is witnessing significant growth due to the rising demand for network security. With cyber threats becoming more sophisticated, network administrators need robust tools to monitor and detect any suspicious activities within the network. Apparatus for tracing packets through a packet pipeline in an SDN switch offer advanced security features, enabling administrators to identify potential security breaches and take immediate actions to mitigate them. In conclusion, the market for apparatus for tracing packets through a packet pipeline in a software-defined networking switch is experiencing substantial growth due to the increasing complexity of networks, the adoption of cloud computing and virtualization, and the rising demand for network security. As organizations strive for efficient network management and troubleshooting solutions, these apparatus provide the necessary capabilities to ensure smooth network operations and enhanced security. With continuous advancements in SDN technology, the market is expected to witness further growth in the coming years.

The Telefonaktiebolaget LM Ericsson AB invention works as follows

A switch implements a method in a network of software defined networking (SDN), to trace packets through a packet pipeline. The method involves creating a duplicate of a packet received to act as a packet trace. At each flow table that the trace package traverses in the future, the method includes appending the identifier for that flowtable to the recorded route of trace packet, and resubmitting trace packet to this flow table without packet tracing. The method also includes sending the trace packet, along with its recorded route, to a controller at an egresstable.

Background for Apparatus for tracing packets through a packet pipeline in a software-defined networking switch

Software defined networking (SDN), an approach to computer networks, is a split-architecture network where the forwarding plane (data plane) is decoupled. Split architecture networks simplify the implementation of forwarding planes by transferring the intelligence to one or more SDN Controllers. SDN provides a programmable infrastructure that allows for rapid and open innovation on the network layer. A typical SDN network consists of multiple switches that are interconnected and at least one SDN controller which controls the switching behavior.

OpenFlow” is a southbound communication protocol which allows SDN controllers to exchange control plane information between switches and switches within an SDN network. OpenFlow switches include a packet pipeline with one or more flowtables. Each flow entry in a flow table specifies a matching criteria for incoming packets and the set of instructions that should be executed when a packet matches this criteria. The set of instructions can instruct the switch perform various operations on a packet. This includes, but is not limited to, forwarded the packet to a specific port, modified certain bits in packet headers, encapsulated the packet, dropped the packet and directed the packet to another table.

The packet processing pipeline for an OpenFlow switch is extremely complex. An SDN controller, for example, may program the switch’s packet processing pipeline to include multiple flowtables and multiple flow entries in each flow table. The flow entries may include instructions to direct packets into other flow tables within the packet processing pipeline. When a packet fails to follow its intended packet processing route, it is extremely difficult for troubleshooters to solve.

Packet Tracing Techniques can be used to troubleshoot packets that do not follow the intended path of packet processing. In order to use existing packet tracing methods, a switch is required to send each packet to the controller for every flow table the packet traverses within the packet processing pipeline. The controller must also collate all the packets received to determine if they are part of the flow, and keep track of their traversed paths. This takes up valuable bandwidth on the control channel. It can be a complex task for the controller if the packet is altered through the packet processing pipe.

The switch implements a method to trace packets within a packet processing pipe of a SDN network. The method involves receiving a packet and, in response to a decision at a table of trace in the pipeline, creating a copy that will function as a “trace packet”, setting a first indicator and a second indicator, and then directing it to the next flow table. At each subsequent flow in the pipeline, the route that the track packet follows, the method also includes adding an identifier to the route recorded by the record packet.

A network switch configured to act as a switch within a software-defined networking (SDN), to trace packets through a packet processing pipe of the switch. The network device comprises a set one or more processors, and a nontransitory machine-readable medium storing a trace component. When executed by the set one or two processors, the tracing component causes the switch, in response to the determination made at a tracing table that a packet matches a trancing criteria, to receive the packet and create a copy that will function as a ‘trace packet.’ It then sets a first traces indicator, a second traces indicator, directs the packet to the next flow table and, at one or more flow tables that it traverses in the pipeline, in response to

The operations include receiving a packet, responsive to a determination at a trace table in the packet processing pipeline that the packet matches a trace criteria, creating a copy of the packet that is to function as a trace packet, setting a first indicator of the packet, setting a second indicator of the packet, and directing the packet’s route through the packet processing pipeline. These operations include receiving a package, and in response to a decision at a table of a packet processing pipe that it matches a trace criterion, creating a duplicate of the original packet which is to be used as a tracing packet. They also include setting a first indicator and a second indicator for the tracing packet.

The following description describes methods for tracing the packets within a packet pipeline of an SDN switch. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding of the present invention. One skilled in the art will however be able to appreciate that the invention can be implemented without these specific details. Other instances have shown control structures, gate-level circuits, and complete software instructions in a simplified form in order to not obscure the invention. “Those with ordinary skill in this art will be able, using the descriptions provided, to implement the appropriate functionality without excessive experimentation.

Referring to “one embodiment” in the specification is not acceptable. ?an embodiment,? ?an example embodiment,? The phrase “an example embodiment” indicates that an embodiment described could include a certain feature, structure or characteristic. However, not all embodiments will necessarily include this feature, characteristic or structure. These phrases do not always refer to the same embodiment. “Furthermore, if a feature, structure or characteristic is described with respect to an embodiment, one of skill in the art can affect that feature, structural or characteristic with regard to other embodiments, whether or not they are explicitly described.

Bracketed texts and blocks with dashed border (e.g. large dashes and small dashes) can be used to illustrate optional operations which add extra features to embodiments. This does not mean that the blocks with solid border are mandatory in certain embodiments.

The following claims and descriptions use the term “coupled” “In the following description and claims, the terms ‘coupled? Along with their derivatives may be used. These terms are not meant to be synonyms. ?Coupled? ‘Coupled’ is used to show that two or more components, whether or not they are in physical or electrical direct contact, cooperate or interact. ?Connected? “Connected” is used to describe the communication that occurs between two or more elements.

An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals?such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., wherein a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, other electronic circuitry, a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set or one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and/or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of receiving data from other electronic devices over a wireless connection and/or sending data out to other devices via a wireless connection. This radio circuitry may include transmitter(s), receiver(s), and/or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. One or more parts of an embodiment may be implemented using different combinations of software, firmware, and/or hardware.

A network device is an electronic device which communicates with other electronic devices (e.g. other network devices or end-user devices) on the network. Some network devices are “multiple service network devices” “Multiple services network devices” are those that support multiple networking functions, such as routing, bridging and switching, Layer 2 aggregate, session border control and/or Subscriber Management, or support multiple application services, including data, voice and video.

As mentioned above, the packet processing pipelines of SDN switches have become increasingly complex. When packets fail to follow their intended processing path, troubleshooting can be extremely challenging. To troubleshoot packets that do not follow the intended path, packet tracing can be used. In order to use existing packet tracing methods, a switch must send the packet to the controller for every flow table the packet traverses within the packet processing pipeline. The controller must also collate all the packets received to determine if they are part of the flow, and keep track of their traversed paths. This uses up valuable control channel bandwidth. It can be a complex task for the controller if the packet is altered through the packet processing pipe.

Embodiments revealed herein improve on existing packet-tracing techniques, by sending only a single packet per switch, along with an indication that the entire route that the package traversed in packet processing pipeline (e.g. the flow tables and group that the pack traversed), instead of sending the same packet to controller for every flow table the packet traverses within packet processing pipeline as is done in existing packet-tracing techniques. This reduces the control channel bandwidth, and allows for more efficient/optimized tracing. Below, various embodiments will be described in greater detail.

FIG. According to certain embodiments, FIG. 1 shows operations for tracing packets in a pipeline of a SDN switch. Diagram 1 shows an SDN 140 including an SDN Controller 100 (referred simply to as controller 100) as well as an SDN Switch 110 (referred simply to as switch 110). The controller 100, which is communicatively connected to the switch and responsible for its management, is in charge of the switch. The controller 100, for example, may program the switch’s packet processing pipeline using a southbound (e.g. OpenFlow) protocol to control the switching behavior and enable the packet tracking functionality described in this document.

The packet processing pipe 120 of the switch may include one flow table or more. Each flow entry can be one or more flow tables, each of which includes a packet-matching criteria and instructions. The instructions for that flow entry will be executed when an incoming packet matches a flow table’s packet matching criteria. The packet must match the packet matching criteria to be considered a flow. A flow entry’s set of instructions may include instructions to the switch on how to perform different operations on a matching package, including but not limited, forwarding it to a specific port, changing certain bits in its header, encapsulating it, dropping it, or directing it to another flow table.

For illustration purposes, the SDN 140 network is shown with a single control 100 and a sole switch 110. The SDN network may have more than one controller and typically more than one switch. For purposes of illustration, embodiments are described primarily in a context that the SDN Controller 100 and the Switch 110 implement OpenFlow. This is merely an example, and it’s not meant to be restrictive. “It should be understood that packet tracing concepts and techniques described herein may also be implemented with other SDN implementations.

In this example, the packet-processing pipeline 120 of switch 110 contains a trace-table, normal flow-tables (table-0 through table-N), as well as an egress-table. The trace table is an egress table used to enable packet tracking for packets which need to be tracked. In one embodiment, trace table is first (foremost flow table) in the packet processing pipe 120 (it’s the first flow against which incoming packages are matched). In one embodiment of the trace table, as shown in the diagrams, a packet is processed by the following: If a packet meets a trace criteria then create a duplicate of the packet that will function as a “trace packet”, set a first and second trace indicators of the copy, and direct both the original packet and trace packet to the ingress tables.

The normal flow tables (tables-0 to-N) are flow-tables that are used in normal packet processing (non-tracing). In one embodiment, these flow tables can be programmed to provide packet tracing (in addition to normal packet processing). In one embodiment (shown in the diagram), one or more flow tables are programmed in such a way that a packet will be processed as follows: If the first indicator is set, the packet indicates it is a trace, then add an identifier to a route recorded by the flow table, remove the first indicator, and submit the packet back to the flow table. Otherwise, if the indicator is not set, then perform normal packet operations, and then set the value for the first indicator to the value for the second indicator before

The egress is a flowtable to which packets will be directed before they leave a physical port on the switch 110. The egress flow table can be used for sending trace packets to controller 100. In some embodiments an existing egress flow is programmed to provide this functionality. In other embodiments, a new table is added to packet processing pipeline 120. In one embodiment (shown in the diagram), the egress flow table is programmed so that a packet will be processed as follows: If the first trace indication of the package is set, send the packet along with its recorded route to the controller; otherwise, perform normal egress operation.

Click here to view the patent on Google Patents.