Patent Grant
9270605
1. Field
This application relates generally to computer networking, and more specifically to a system, article of manufacture and method for setting network traffic flow quality of service (QoS) by modifying port numbers.
2. Related Art
Conventional methods of network services provide Quality of Service (QoS). Few non-limiting examples are based on COS values (layer 2 header) or TOS values (layer 3 header). Intermediate switches and routers can be configured to change these fields based on various parameters, a non-limiting example can be looking at the 5-tuple of the packet, 5-tuple consists of source IP, source port, destination IP, destination port, and protocol. Various network attributes such variable bit rate and delivery time may depend on various current states of the network such as the current traffic load.
Deep packet inspection is another non-limiting option to classify the flow and provide QoS. Intermediate devices (e.g. routers and/or switches) in the network may not be configurable to efficiently inspect the deeper layers of the data packets and provide QoS or priority according to their contents. Moreover, in-line deep packet inspection can increase networking latency, decrease throughput and reduce QoS.
Even if intermediate devices (e.g. routers and/or switches) can support deep packet inspection, customized classifying logic might not be present on these devices. Hence, this may require a customized software loaded on these intermediate devices, which is not very common.
Data packets are segmented when an application utilizes large packet sizes greater than the path MTU (Maximum Transmission Unit). Data packet segmentation can cause the header to be separated from the other segments of the data packet. Thus, conventional attempts to provide a QoS level based on current methods of inspecting data packet headers can be problematic. Accordingly, improvements can be made over conventional methods of setting network traffic flow QoS.
In one aspect, a method of managing computer network traffic flow quality of service includes the step of configuring a configurable network device to provide a specified quality of service to a data packet with a specified quality of service configuration based on a quality of service classification port number in a data packet header of the data packet. At the source node, a data packet is generated with a destination port number in the data packet header. At the source node, the destination port number in the data packet header is replaced with a quality of service classification port number associated with the specified quality of service. At the source node, the destination port number is included in an options field of the data packet's header. The data packet is communicated to the configurable network device. At a destination node, the data packet can be received. The quality of service classification port number can be replaced with the destination port number in the options field of the data packet header. The data packet can be forwarded to a destination process with the destination port number.
The present application can be best understood by reference to the following description taken in conjunction with the accompanying figures, in which like parts may be referred to by like numerals.
The Figures described above are a representative set, and are not an exhaustive with respect to embodying the invention.
Disclosed are a system, method, and article of setting network traffic flow quality of service (QoS) by modifying port numbers. The following description is presented to enable a person of ordinary skill in the art to make and use the various embodiments. Descriptions of specific devices, techniques, and applications are provided only as non-limiting examples. Various modifications to the examples described herein may be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the various embodiments.
Reference throughout this specification to “one embodiment,” “an embodiment,” “one example,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
Furthermore, the described features, structures, or characteristics of the invention may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art can recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, components, materials, and so forth. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
The schematic flow chart diagrams included herein are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of one embodiment of the presented method. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated method. Additionally, the format and symbols employed are provided to explain the logical steps of the method and are understood not to limit the scope of the method. Although various arrow types and line types may be employed in the flow chart diagrams, and they are understood not to limit the scope of the corresponding method. Indeed, some arrows or other connectors may be used to indicate only the logical flow of the method. For instance, an arrow may indicate a waiting or monitoring period of unspecified duration between enumerated steps of the depicted method. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.
Traffic flows 108 and 110 can manage the transmission of a data packets between nodes of DDBS 100 based on a pre-determined QoS classification. By way of example and not limitation, nodes 102 A-C of DDBS 100 can provide information in the data packet's various networking layer headers (e.g. a first segment of a data packet and/or supplemental data at the beginning of a data block). For example, nodes 102 A-C can include an operating system that modifies destination information in the networking layer headers to signify both original source and/or destination ports but also the classification of the traffic flow (e.g. with respect to QoS) of the particular data packet and/or data packet segment.
In some embodiments, the application information layers five to seven may not be visible to the networking devices in network 104 (e.g. not practical to inspect by intermediate configurable switches/routers 106). However, the networking devices can access the 5-tuple information in the networking headers of the data packet. For example, source and/or destination port numbers in the TCP/IP transmission layer header of a data packet can be read by intermediate configurable switches/routers 106. Accordingly, information applicable to classifying traffic flows can be provided to intermediate configurable switches/routers 106 as QoS codes in place of the original destination port numbers provided by the source application(s) in nodes 102 A-C. These QoS classification port numbers can then be used by intermediate device to prioritize various data packets in network 104. In this way, the classification of traffic flows 108 and 110 can be based on information originally located deeper in the data packet (e.g. in layer-5 (L5) to layer-7 (L7) networking headers) without inspection of these layers. Non-limiting examples of these traffic flows can include Hadoop Distributed File System (HDFS) data traffic, iSCSI control traffic, iSCSI data traffic, Thrift protocol message traffic, Cassandra® traffic, Hadoop job tracker traffic, and the like.
Data packets may also be segmented into smaller units (e.g. ‘fragments’) and communicated across network 104. As used herein, data packet segmentation can include the process of dividing a data packet into smaller units for transmission over the network. Since classification of traffic flows 108 and 110 are performed at the source node where the segmentation is also performed, these fragments can also be marked with the same QoS classification port numbers, and can have the same QoS applied as the first segment in the respective traffic flow.
In some embodiments, DDBS 100 can be any distributed data storage system. In some non-limiting examples, DDBS 100 can include a distributed file system (e.g. a clustered filed system such a Hadoop Distributed File System (HDFS), and/or any other distributed file system provided herein). Accordingly, nodes 102 A-C can be implemented as a Hadoop cluster. In still other non-limiting example embodiments, DDBS 100 can include an open source distributed database management system such as Cassandra®. Moreover, in some embodiments, nodes 102 A-C can be implemented as virtual nodes. Indeed, in some example embodiments, DDBS 100 can be implemented as a virtual system in all and/or in part. These examples are provided by way of example and not of limitation.
In some embodiments, before sending a data packet, nodes 102 A-C can classify the application payload at the source node TCP/IP layer (e.g. of the TCP/IP model). This classified traffic can be mapped to a different destination port using various techniques.
Accordingly, intermediate network devices 106 can be configured to provide various QoS modes to data packets based on a 5-tuple classification system. TCP/IP packet classification can be done based on 5-tuple (source IP, destination IP, Protocol, source Port, destination port). This information can be available by inspecting up to the layer-4 headers of the packets. Intermediate router(s) and/or switch(es) 106 can inspect these fields and support classification of the data packet in terms of a network QoS mode based on its respective 5-tuples value. The intermediate router(s) and/or switch(es) 106, in turn, can be configurable (e.g. from a management module 112). In this way, different virtual paths (e.g. control paths, data paths, messaging paths, etc.) can be created across the cluster(s) of DDBS 100.
Management module 112 can be used to configure intermediate router(s) and/or switch(es) 106. One non-limiting example may be, a console and/or dashboard can be provided that enables an administrative entity to create various virtual paths in the clusters of DDBS 100. In which certain QoS modes can be matched to a specified the destination port portion of the TCP layer header.
Traffic flow classifier 306 (and traffic flow classifier 314) can modify the port number information in the outgoing data packet 320 B. Data packet 320 B shows the original source IP address in a top box with source port number at the end. Data packet 320 B shows the original destination IP address in a top box with QoS classification port number at the end. Traffic flow classifier 306 can provide a new destination port number of ‘5000’. The new destination port number can be used to create a virtual path between node X 302 and node Y 309 in network 316. A non-limiting example nay be, the new destination port number can be provided based on a pre-determined set of QoS control codes 322. The intermediate devices 318 can be configured to provide QoS to data packet 320 B based on QoS control codes 322 (e.g. C1, C2, C3, etc. each representing a predetermined QoS mode). QoS control codes 322 can be defined using a management console.
In this way, virtual paths can be created in network 316 such that the classified traffic flows behave in a deterministic manner. Traffic flow classifier 306 can place the original destination port provided by source application 304 in a TCP/IP options section of the TCP/IP header portion of the data packet 320 B. The TCP/IP protocol can enable a selection of up to four thousand port numbers. Certain number of the ports can be set aside for QoS classification purposes. Thus, when node Y 309 receives the data packet 320 B, destination port correction module 308 can modify data packet 320 B back to its original state as data packet 320 A by replacing the QoS control codes (e.g. ‘5555’) with the original destination port number (e.g. ‘4444’) by consulting the TCP/IP options section. Data packet 320 A can then be provided to destination application 310 which is listening at port 20. It is noted that the networking layer of system 300 (e.g. network 316 and configurable intermediate device 318) need not perform deep packet inspection to determine the QoS classification of the various data packets. Furthermore, source application 304 and destination application 310 do not need to be modified to perform the operations provided in
It is noted, that in some embodiments, non-classified and/or external traffic can be accommodated with minimal effect when flowing through an intermediate gateway and/or routers that are configured to act on the classification scheme as provided herein. Additionally, it is noted that the examples provided in
It is noted that the methods and systems provided supra can be implanted in a data-center environment (e.g. with a host-to-host ‘east-west’ traffic pattern). For example, the data-center environment can span multiple datacenters with wide area network (WAN) links implemented between said datacenters. The data-center environment can be implemented in a cloud-computing environment and include various available scalable architectures. For example, a front-end server can ‘consult’ several other worker servers within the data-center environment before it returns an aggregated response back to a client. In some examples, the ‘east-west’ traffic can also be virtualization driven (e.g. with virtual servers syncing up with one another).
In one example, the option-kind subfield 604 can be a specified length (e.g. one byte in length). The option-length subfield 606 can be two bytes. The option data/padding subfield 608 can be used to include the original destination port number. This may be included without the need for additional padding. These non-limiting examples are provided by way of example of not of limitation.
Although the present embodiments have been described with reference to specific example embodiments, various modifications and changes can be made to these embodiments without departing from the broader spirit and scope of the various embodiments. For example, the various devices, modules, etc. described herein can be enabled and operated using hardware circuitry, firmware, software or any combination of hardware, firmware, and software (e.g., embodied in a machine-readable medium).
In addition, it may be appreciated that the various operations, processes, and methods disclosed herein can be embodied in a machine-readable medium and/or a machine accessible medium compatible with a data processing system (e.g., a computer system), and can be performed in any order (e.g., including using means for achieving the various operations). Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. In some embodiments, the machine-readable medium can be a non-transitory form of machine-readable medium.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5941988 | Bhagwat | Aug 1999 | A |
| 6449251 | Awadallah | Sep 2002 | B1 |
| 6563824 | Bhatia | May 2003 | B1 |
| 8429630 | Nickolov | Apr 2013 | B2 |
| 20150120897 | Colin | Apr 2015 | A1 |
| 20150281060 | Xiao | Oct 2015 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20150350094 A1 | Dec 2015 | US |
