Search

EP-4466837-B1 - PROCESSING QUEUE ASSIGNMENT BASED ON A FLAG IN A GENEVE HEADER

EP4466837B1EP 4466837 B1EP4466837 B1EP 4466837B1EP-4466837-B1

Inventors

  • YANG, GUOLIN
  • SERRA MIRALLES, EDUARD
  • WANG, Dexiang
  • CHANG, QING

Dates

Publication Date
20260506
Application Date
20230118

Claims (9)

  1. A method (130) comprising: in a first computing system (110): identifying (201) a packet to be encapsulated and forwarded to a second computing system (111); determining (202) that the packet comprises a control packet (162) based on values in the packet; in response to determining that the packet comprises a control packet (162), encapsulating (203) the packet as a generic network virtualization encapsulation, Geneve, packet (160), wherein an Operations and Management, OAM, flag (163) is set in a header of the Geneve packet (160) based on the packet comprising a control packet (162); and communicating (204) the Geneve packet (160) toward the second computing system (111); and in the second computing system (111): receiving (310) the Geneve packet (160) at a network interface; determining (302) that the Geneve packet (160) includes the OAM flag (163); wherein the method is further characterized in that in the second computing system : in response to determining that the Geneve packet (160) includes the OAM flag (163), selecting (303) a processing queue from a plurality of processing queues for a main processing system of the second computing system (111) based on the OAM flag (163); assigning (304) the Geneve packet (160) to the processing queue; and periodically updating the processing queue to prevent possible attacks using packets that could be assigned to the processing queue.
  2. The method (130, 151) of claim 1 further comprising: in the second computing system (111): receiving a second packet at the network interface; determining that the second packet does not include a set OAM flag (163); in response to determining that the second packet does not include the set OAM flag (163), selecting a second processing queue from the plurality of processing queues based on the second packet not including the set OAM flag (163); and assigning the second packet to the second processing queue.
  3. The method (130, 151) of claim 2, wherein the processing queue comprises a quality of service better than the second processing queue.
  4. The method (130, 151) of claim 2, wherein the processing queue is allocated a first set of processing resources for the main processing system of the second computing system (111), and wherein the second processing queue is allocated a second set of processing resources for the main processing system.
  5. The method (130, 151) of claim 4, wherein the first set of processing resources comprises a first processing core allocation, a first clock cycle allocation, or a first memory allocation, and wherein the second set of processing resources comprise a second processing core allocation, a second clock cycle allocation, or a second memory allocation.
  6. The method (130, 151) of any one of claims 1 to 5 further comprising: in the main processing system of the second computing system (111): obtaining the Geneve packet (160) from the processing queue; decapsulating the Geneve packet (160) to obtain the packet; and forwarding the packet to a destination appliance.
  7. The method (130, 151) of any one of claims 1 to 6, wherein determining that the Geneve packet (160) includes the OAM flag (163), selecting the processing queue from the plurality of processing queues for the main processing system, and assigning the Geneve packet (160) to the processing queue comprises: in network interface processing system of the second computing system (111): determining that the Geneve packet (160) includes the OAM flag (163); selecting the processing queue from the plurality of processing queues for the main processing system; and assigning the Geneve packet (160) to the processing queue.
  8. A non-transitory computer-readable medium comprising executable instructions, wherein the instructions, when executed by at least one processor, cause at least one processor to carry out the method (130; 151) of any one of claims 1 to 7.
  9. A system (100) comprising: a first computing system (110); and a second computing system (111), wherein the system (100) is configured to perform the method (130; 151) of any one of claims 1 to 7.

Description

TECHNICAL BACKGROUND In computing environments, software defined networks (SDNs) may be used that comprise software modules or appliances capable of providing a communication platform for one or more virtual nodes in the computing environment. The SDNs, which may include virtual switches, routers, distributed firewalls, and the like, may be used to intelligently direct communication on the network by inspecting packets before passing them to other nodes on the same network. To provide the required operations, SDNs may be separated into a data plane, which is used to manage communications for active nodes (virtual machines and containers) in the computing environment, and a control plane, which is used to configure the various virtual switches, routers, distributed firewalls, and the like, as well as identify the operational status of elements within the computing environment. In some implementations, SDNs use control packets, such as Bidirectional Forwarding Detection (BFD) packets, Border Gateway Protocol (BGP) packets, and other similar control packets, which have the requirement of reliable and timely delivery. If, for any reason not related to network failure, the control packets are not delivered within a certain period, unnecessary actions (such as fail over to a standby node or tear down of a BGP session) will be taken based on the assumption that a network failure has occurred. Using BFD as an example, control packets could be exchanged between transport nodes (hypervisors or gateway nodes, such as Virtual Extensible Local Area Network (VXLAN) tunnel endpoints (VTEPs)), between gateway nodes in a gateway cluster, or between a gateway and a remote router. In an SDN, when control packets are communicated over virtual network interfaces and/or physical network interfaces, the control packets will be mixed with other data packets which are less sensitive to packet drops or delays. Under high load, those control packets can be dropped or significantly delayed by the network interface, which may cause various unnecessary disruptions to the network functions. Recently, Geneve has become a popular encapsulation protocol for SDN because of its extensibility, among other reasons. Request for Comments (RFC) 8926 promulgated by the Internet Engineering Task Force (IETF) expresses the Geneve protocol standard and defines the format for the Geneve encapsulation header. The proposed standard defines the header format that includes a one-bit "OAM Packet" field that indicates the packet is an Operations, Administration, and Maintenance (OAM) protocol packet. The Geneve standard requires that when this bit is set, "endpoints MUST NOT forward the payload and transit devices MUST NOT attempt to interpret or process it." The standards document further states that "it is RECOMMENDED that endpoints direct these packets to a high priority control queue." As further explained in an Internet-Draft entitled "OAM for use in GENEVE" prepared by the NVO3 Working Group for the IETF, dated March 9, 2020, the OAM protocols provide a control channel between Geneve tunnel endpoints for fault detection, diagnostics, maintenance, and other functions, where "such a control tunnel is dedicated to carrying only control and management data between tunnel endpoints" and that OAM packets received over the tunnel should not be forwarded. While Geneve-aware physical NICs can be configured to separately queue and prioritize OAM packets, the OAM protocols are often not implemented between endpoints, which opens the OAM field for other uses. NVO3 Working Group's "BFD for Geneve" describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Generic Network Virtualization Encapsulation (Geneve) tunnels used to make up an overlay network. IETF's RFC 8926 "Geneve: Generic Network Virtualization Encapsulation" Geneve, an encapsulation protocol designed to recognize and accommodate changing capabilities and needs, due to network virtualization involving the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. SUMMARY The technology described herein manages the identification of control packets in encapsulation packet. The invention is defined by the independent claims. Further embodiments of the invention are defined by the dependent claims. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates a computing environment to identify control packets in an encapsulation header according to an implementation.Figure 2 illustrates an encapsulate operation of a computing system to encapsulate a control packet according to an implementation.Figure 3 illustrates a queue select operation of a computing system to select a queue for an encapsulated packet according to an implementation