System and method for differentiating services through in-band signaling

Abstract

A device includes: a network interface for connecting to a network; a database for storing traffic shaping parameters of a traffic shaping scheme for multiple categories of data packets; a database loading circuit for obtaining the traffic shaping parameters from in-band communications received by the network interface in data packets and loading the traffic shaping parameters into the database; and one or more traffic shapers: for accessing the traffic shaping parameters in the database and applying the traffic shaping scheme to the multiple categories of data packets received by the network interface according to the traffic shaping parameters.

Description

Technical Field

[0001] The present invention relates to a technology for providing differentiated services in a network. Background Art

[0002] The Internet Protocol (IP) is the most widely used technology at layer 3 of the Open System Interconnection (OSI) model of the Internet. At layer 4 of the OSI model, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) are the most widely used protocols for IP networks. The design of the Internet Protocol is based on the end-to-end principle. The network infrastructure is considered to be inherently unreliable on any single network element or transmission medium, and is dynamic in terms of the availability of links and nodes. There are no central monitoring or performance measurement facilities to track or maintain the status of the network. In order to reduce network complexity, intelligent devices in the network can be located in terminal nodes. Summary of the invention

[0003] According to one aspect of the present invention, a device is provided. The device includes: a network interface for connecting to a network; a database for storing traffic shaping parameters of a traffic shaping scheme for multiple categories of data packets received by the network interface; a database loading circuit for obtaining the traffic shaping parameters from in-band communications received by the network interface in a data packet and loading the traffic shaping parameters into the database; and one or more traffic shapers for accessing the traffic shaping parameters in the database and applying the traffic shaping scheme to the multiple categories of data packets received by the network interface according to the traffic shaping parameters.

[0004] Optionally, in any of the above aspects, the one or more traffic shapers include an egress shaper, which is configured to send one category of data packets to multiple queues associated with the multiple categories of data packets.

[0005] Optionally, in any of the above aspects, the multiple queues include two or more queues managed by a weighted fair queuing scheduler and a priority queue managed by a priority scheduler.

[0006] Optionally, in any of the above aspects, the one or more traffic shapers include an ingress shaper, which is used to instruct data packets marked as a first category to be re-marked as one or more other categories.

[0007] Optionally, in any of the above aspects, the traffic shaping scheme is a single rate Three Color Marker (srTCM) scheme for the multiple categories of data packets.

[0008] Optionally, in any of the above aspects, the traffic shaping scheme is a two rate Three Color Marker (trTCM) scheme.

[0009] Optionally, in any of the above aspects, the traffic shaping parameters include a committed information rate (CIR), a committed burst size (CBS) and an exceeded burst size (EBS).

[0010] Optionally, in any of the above aspects, the traffic shaper is used to re-mark the data packets belonging to the first category as belonging to the second category, or to place the data packets belonging to the first category in a queue of at least the second category.

[0011] Optionally, in any of the above aspects, the in-band communication is located in a hop-by-hop extension header of an IPv6 data packet.

[0012] According to another aspect of the present invention, a method for operating a network device is provided. The method comprises: receiving a first data packet through a network interface of the network device; obtaining traffic shaping parameters of a traffic shaping scheme for multiple categories of data packets from in-band communications received in the first data packet; and storing the traffic shaping parameters in a database in the network device. The method further comprises: receiving a plurality of data packets through the network interface of the network device; identifying the corresponding categories of the plurality of data packets; and shaping the traffic in the network device according to the identified categories using one or more traffic shapers configured according to the traffic shaping parameters stored in the database.

[0013] Optionally, in any of the above aspects, shaping the traffic in the network device includes sending one category of data packets to multiple queues associated with the multiple categories of data packets.

[0014] Optionally, in any of the above aspects, the method further includes: selecting a data packet from the multiple queues in the weighted fair queue scheduling scheme and the strict priority scheduling scheme.

[0015] Optionally, in any of the above aspects, shaping the traffic in the network device includes re-marking data packets marked as belonging to the first category as belonging to at least a second category.

[0016] Optionally, in any of the above aspects, shaping the traffic in the network device using one or more traffic shapers according to the identified categories includes applying a single rate Three Color Marker (srTCM) scheme for the multiple categories of data packets.

[0017] Optionally, in any of the above aspects, shaping the traffic in the network device using one or more traffic shapers according to the identified categories includes applying a tworate Three Color Marker (trTCM) scheme for the multiple categories of data packets.

[0018] Optionally, in any of the above aspects, obtaining the traffic shaping parameters of the traffic shaping scheme includes obtaining a committed information rate (CIR), a committed burst size (CBS) and an exceeded burst size (EBS).

[0019] Optionally, in any of the above aspects, traffic shaping includes at least one of the following steps: re-marking data packets marked as belonging to a first category as belonging to a second category and placing data packets belonging to the first category in a queue of at least the second category.

[0020] Optionally, in any of the above aspects, obtaining the traffic shaping parameters includes reading a hop-by-hop extension header of an IPv6 data packet.

[0021] According to another aspect of the present disclosure, a system is provided. The system includes a plurality of network devices coupled to a network. Each of the plurality of network devices includes: a network interface for connecting to the network; a database for storing traffic shaping parameters of a traffic shaping scheme for multiple categories of data packets received by the network interface; a database loading circuit for obtaining the traffic shaping parameters from in-band communications received by the network interface in a data packet; and one or more traffic shapers for accessing the traffic shaping parameters in the database and applying the traffic shaping scheme to the multiple categories of data packets received by the network interface according to the traffic shaping parameters.

[0022] Optionally, in any of the above aspects, the one or more traffic shapers include an egress shaper, which is configured to send one category of data packets to multiple queues associated with the multiple categories of data packets.

[0023] Optionally, in any of the above aspects, the multiple queues include two or more queues managed by a Weighted Round Robin (WRR) scheduler and a priority queue managed by a priority scheduler.

[0024] Optionally, in any of the above aspects, the one or more traffic shapers include an ingress shaper, which is used to instruct data packets marked as a first category to be re-marked as one or more other categories.

[0025] Optionally, in any of the above aspects, the traffic shaping scheme is a single rate Three Color Marker (srTCM) scheme for the multiple categories of data packets.

[0026] Optionally, in any of the above aspects, the traffic shaping scheme is a two rate Three Color Marker (trTCM) scheme.

[0027] Optionally, in any of the above aspects, the traffic shaping parameters include a committed information rate (CIR), a committed burst size (CBS) and an exceeded burst size (EBS).

[0028] Optionally, in any of the above aspects, the traffic shaper is used to re-mark the data packets belonging to the first category as belonging to the second category, or to place the data packets belonging to the first category in a queue of at least the second category.

[0029] Optionally, in any of the above aspects, the in-band communication is located in a hop-by-hop extension header of an IPv6 data packet.

[0030] According to another aspect of the present invention, a method is provided. The method comprises: obtaining traffic shaping parameters of multiple categories of data packets from in-band signaling received at a network device side; receiving multiple data packets at the network device side. The method further comprises: identifying a corresponding category of each of the multiple categories of data packets; and shaping the multiple data packets according to the traffic shaping parameters of the multiple categories of data packets, so that at least a first category of data packets is distributed between a queue of the first category and a queue of a second category.

[0031] According to another aspect of the present invention, a method for operating a network device is provided. The method comprises: receiving a first IPv6 data packet through a network interface of the network device; obtaining traffic shaping parameters of a traffic shaping scheme for multiple categories of data packets from a hop-by-hop extension header of the first IPv6 data packet; and storing the traffic shaping parameters in a database in the network device. The method also comprises: receiving multiple IPv6 data packets through the network interface of the network device; identifying corresponding categories of the multiple IPv6 data packets according to the Differentiated Services Code Point (DSCP) field in the headers of the multiple IPv6 data packets; and shaping the traffic in the network device according to the identified categories using one or more traffic shapers configured according to the traffic shaping parameters stored in the database.

[0032] This summary is provided to introduce in simplified form some concepts further described in the following detailed description. The purpose of this summary is not to identify the key features or essential features of the subject matter for which protection is sought, nor is it to help determine the scope of the subject matter for which protection is sought. The subject matter for which protection is sought is not limited to implementations that address any or all of the shortcomings noted in the background technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The present invention in its various aspects is illustrated by way of example and not limitation in the accompanying figures, in which like reference numerals indicate elements thereof.

[0034] Figure 1 A schematic diagram of a network provided for an embodiment of the present invention.

[0035] Figure 2 A method for establishing a connection with a differentiated service provided by an embodiment of the present invention is shown.

[0036] Figure 3 A method for checking the status of a connection with differentiated services provided by an embodiment of the present invention is shown.

[0037] Figure 4A method for establishing a connection with differentiated services provided by an embodiment of the present invention is shown.

[0038] Figure 5 A method for checking the status of a connection with differentiated services provided by an embodiment of the present invention is shown.

[0039] Figure 6 A method for establishing a connection with differentiated services provided by an embodiment of the present invention is shown.

[0040] Figure 7 A method for checking the status of a connection with differentiated services provided by an embodiment of the present invention is shown.

[0041] Figure 8 A method for providing differentiated services through traffic shaping provided by an embodiment of the present invention is shown.

[0042] Fig. 9A A network device configured according to one embodiment of the present invention is shown.

[0043] Fig. 9B An example of the operation of a network device provided by an embodiment of the present invention is shown.

[0044] Fig.10 An example of the operation of a network device provided by an embodiment of the present invention is shown.

[0045] Fig.11 An example of a method provided by an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0046] The present invention is described below with reference to the accompanying drawings. Figure 1 Generally involves networks, network devices within a network, and their configuration and operation.

[0047] In some networks, different data packets may have different QoS requirements. Data packets may be classified into different categories, each of which has a corresponding QoS requirement. In some cases, network devices may be used to provide differentiated services for these data packets through separate configuration of each network device on the data path. For example, the network devices may be individually loaded with appropriate software or firmware that supports differentiated services, and may be configured by configuration commands from an administrator (e.g., by configuration commands from an administrator device that point to a single device for configuration). However, such separate configuration may not be ideal. According to one example of the current technology, in-band communication is used to efficiently configure network devices in a network to provide end-to-end differentiated services in the network in a manner that does not require separate configuration. The term "in-band communication" or "in-band signaling" generally refers to sending or receiving management traffic, such as regular network traffic, over a network (e.g., sending management traffic in data packets, where these data packets are transmitted along the same data path, and these data paths include the same ports as regular network traffic). This is in contrast to out-of-band communication, which may use a dedicated communication channel for management traffic separated from normal network traffic. Such in-band communication may be provided in an extension header of an IPv6 packet that is received by a network device (e.g., by multiple routers on a data path). Configuration information obtained from the in-band communication (e.g., traffic shaping parameters to be used by the router) may be loaded into a database in the network device and may be used to configure a traffic shaper to shape data traffic as needed. In-band communication may also indicate when the network device may or may not comply with class-based QoS requirements. Traffic shaping implemented by the network device may identify the class associated with the packet by reading the header information, and may then apply traffic shaping indicated by traffic shaping parameters previously loaded into a database in the router (e.g., obtained from the in-band communication information and loaded into the database). Different flows may be mapped to a class, and the QoS requirements (and corresponding traffic shaping parameters) for that class may be determined by combining the QoS requirements of the individual flows corresponding to that class.

[0048] It should be understood that the current embodiment of the present invention can be realized by many different forms, and the scope of the claims should not be construed as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided to make the present invention thorough and complete, and to fully convey the inventive embodiment concepts to those skilled in the art. In fact, the purpose of the present invention is to cover the substitutes, modifications and equivalents of these embodiments, which are included in the scope and spirit of the present invention as defined by the appended claims. In addition, in the following detailed description of the current embodiment of the present invention, many specific details are set forth in order to provide a thorough understanding. However, it is clear to those of ordinary skill in the art that the current embodiment of the present invention can be implemented without providing these specific details.

[0049] Figure 1 A schematic diagram of a network 100 is provided for one embodiment of the present invention. The network 100 includes a device 110 and a device 120, and a router 130 and a router 140 that couple the device 110 with the device 120. The device 110 and the device 120 can send Internet Protocol (e.g., Internet Protocol version 6 (IPv6)) packets to each other via the router 130 and the router 140 (although the example of IPv6 packets is used in this document, it should be understood that the current technology is not limited to any specific protocol). In some embodiments, the network 100 includes more routers between the device 110 and the device 120. However, for the sake of simplicity, Figure 1 Only two routers are shown. Devices 110 and 120 may be personal computers, servers, routers, smart phones, laptops, etc. Devices 110 and 120 may be edge devices in network 100 and may be used as ingress modules and egress modules in network 100. Devices 110 and 120, routers 130 and 140, and similar devices that exchange data packets through a network may be considered network devices.

[0050] Figure 2 A method for establishing a connection through the network 100 through in-band signaling provided by an embodiment of the present invention is shown.

[0051] In operation 210, device 110 sends a first IPv6 data packet 150 including a Transmission Control Protocol (TCP) synchronization (SYN) segment 151 to router 130. The first IPv6 data packet 150 is used to establish a connection between device 110 and device 120, and the destination IPv6 address of the first IPv6 data packet is the IPv6 address of device 120. The connection can be determined based on some information in the IPv6 data packet. In one example, when the data packets have the same source IP address and the same destination IP address, and also have the same source port, the same destination port and protocol number, the data packets are considered to belong to the same connection. The connection can be called a path. The first IPv6 data packet 150 also includes a hop-by-hop extension header 152. The hop-by-hop extension header 152 can be between the IPv6 header 153 and the TCP SYN segment 151, and carry one or more class-based QoS requirements 154 for the upstream connection.

[0052] In some examples, data packets may be classified into different categories, and the QoS requirements may include one or more category-based QoS requirements corresponding to the used categories, so that differentiation of service information is sent in these headers. The category-based QoS requirements may include traffic shaping parameters for traffic shaping according to the different service levels required. The uplink connection refers to the connection from device 110 to device 120. In some embodiments, when an IPv6 data packet carrying a hop-by-hop extension header is received by multiple routers between a source node and a destination node, each router checks the hop-by-hop extension header (e.g., parses the IPv6 data packet and reads a value from the hop-by-hop extension header). For example, the content of the hop-by-hop extension header is read by the router, so some actions can be performed according to the instructions carried in the hop-by-hop extension header. For example, some information can be added or updated to the hop-by-hop extension header. The source node and the destination node of the IPv6 data packet can also check the hop-by-hop extension header. In some examples, the network device can perform some configurations based on the information provided in the hop-by-hop extension header to meet one or more category-based QoS requirements. For example, the network device can perform internal configuration of the traffic shaper based on the received traffic shaping parameters to ensure that each category of data packets is properly processed to meet the required QoS.

[0053] An example of a hop-by-hop extension header may be a hop-by-hop options header defined in RFC 2460. The entire contents of RFC 2460 are incorporated herein by reference. According to RFC 2460, any IPv6 data packet including a hop-by-hop options header needs to be checked by each router (e.g., all routers, devices 110, and devices 120 on a connection) that receives the IPv6 data packet. Specifically, the hop-by-hop options header is used to carry optional information that must be checked by each node on the transmission path of the data packet. The hop-by-hop options header is identified by a next header with a value of 0 in the IPv6 header, and the format of the hop-by-hop options header is shown in Table 1.

[0054] Table 1

[0055] Next Head Hdr Ext Len Options

[0056] The Next Header of the Hop-by-Hop Extension Header shown in Table 1 is an 8-bit selector that identifies the type of header that immediately follows the Hop-by-Hop Options Header. The Next Header can use the same value as the IPv4 Protocol field [RFC-1700 et seq]. Hdr ExtLen is an 8-bit unsigned integer indicating the length of the Hop-by-Hop Options Header in units of 8 octets, excluding the first 8 octets. Options is a variable length field such that the length of the complete Hop-by-Hop Options Header is an integer multiple of 8 octets. Options includes one or more TLV-encoded options.

[0057] In addition to the Hop-by-Hop Options header defined in RFC 2460, some other examples of Hop-by-Hop extension headers may be further defined.

[0058] The class-based QoS requirement 154 includes values ​​of some parameters of the upstream connection. These parameters may include information associated with the QoS of the upstream connection of two or more data packet classes. The QoS parameters may be related to the bandwidth and delay specified for the class. In one example, the bandwidth may refer to a range between a low bandwidth value and a high bandwidth value. The class-based QoS requirement 154 may indicate that the first IPv6 data packet is used to establish an upstream connection with QoS guarantee for each specified class. For example, the bandwidth of the upstream connection with QoS guarantee for the first class of data packets is not less than a value included in the class-based QoS requirement, such as 5 Mb / s, and the delay of the upstream connection with QoS guarantee for the second class of data packets is not less than another value included in the class-based QoS requirement.

[0059] In operation 220, the router 130 receives the first IPv6 data packet 150 and obtains the class-based QoS requirement 154 in the hop-by-hop extension header 152. The router 130 determines whether its ability to forward data packets of the upstream connection meets (or can be configured to meet) the class-based QoS requirement 154 corresponding to the specified class, and can perform appropriate configuration accordingly to ensure that the QoS requirement corresponding to each class is met. If the ability meets the class-based QoS requirement 154, the router 130 configures its hardware (e.g., using the traffic shaping parameters in the class-based QoS requirement 154) so ​​that the router 130 forwards the data packets of the upstream connection according to the class-based QoS requirements 154 corresponding to different classes (e.g., prioritizes data packets in a class with low latency requirements). The router 130 can also modify the first IPv6 data packet 150 by setting the hop-by-hop extension header 152 to indicate that the router 130 meets (is configured to meet) the class-based QoS requirement corresponding to the specified class. For example, the router 130 may update the first setup state 155 in the hop-by-hop extension header 152 to indicate that the router 130 meets the class-based QoS requirement, wherein the setup state 155 is located in the first setup state field in the hop-by-hop extension header 152. If the router 130 does not meet the class-based QoS requirement, the router 130 may modify the first IPv6 data packet 150 by setting the hop-by-hop extension header 152 to indicate that the router 130 does not meet the class-based QoS requirement. For example, the router 130 may update the first setup state 155 in the hop-by-hop extension header 152 to indicate that the router 130 does not meet the class-based QoS requirement.

[0060] According to the QoS implementation method, the first establishment status field may also include additional information of the QoS configuration state. The additional information may include data of a limited size (mapping index) used as a reference to the QoS configuration database. By using the reference, the IP forwarding program or hardware can quickly retrieve more details of the QoS configuration state, such as the classification ID, scheduler ID, queue ID, etc., to speed up IP forwarding while ensuring quality.

[0061] In operation 230 , the router 130 sends the modified first IPv6 data packet 150 to the router 140 according to the destination IP address of the first IPv6 data packet 150 .

[0062] In operation 240, the router 140 receives the first IPv6 packet 150 from the router 130 and obtains the class-based QoS requirement 154 in the hop-by-hop extension header 152. Similar to the router 130, the router 140 determines whether its ability to forward packets of the upstream connection meets the class-based QoS requirement 154 corresponding to the indicated class. If the ability of the router 140 meets the class-based QoS requirement 154, the router 140 configures its hardware according to the class-based QoS requirement (e.g., configures traffic shaping according to traffic shaping parameters) so that the router 140 forwards packets of the upstream connection according to the class-based QoS requirements 154 corresponding to different classes (e.g., prioritizes packets in a class with a low latency requirement). The router 140 may also modify the first IPv6 packet 150 by setting the hop-by-hop extension header in the first IPv6 packet to indicate that the router 140 meets (is configured to meet) the first QoS requirement. For example, the router 140 may update the second setup state 156 in the hop-by-hop extension header to indicate that the router 140 meets the class-based QoS requirement, wherein the second setup state 156 is located in the second setup state field in the hop-by-hop extension header. If the router 140 does not meet the class-based QoS requirement 154, the router 140 may modify the first IPv6 data packet 150 by setting the hop-by-hop extension header 152 to indicate that the router 140 does not meet the class-based QoS requirement. For example, the router 140 may update the setup state in the hop-by-hop extension header 152 to indicate that the router 140 does not meet the class-based QoS requirement 154. In some embodiments, the first setup state field and the second setup state field are two different fields in the hop-by-hop extension header. In some embodiments, the first setup state field and the second setup state field refer to the same field in the hop-by-hop extension header that includes two or more setup states.

[0063] In operation 250 , the router 140 sends the first IPv6 data packet modified by the router 140 to the device 120 according to the destination IP address of the first IPv6 data packet.

[0064] In operation 260 , the device 120 receives the first IPv6 packet 150 from the router 140 and determines that each router on the upstream connection is configured to meet the class-based QoS requirements 154 corresponding to each class specified in the hop-by-hop extension header 152 .

[0065] In operation 270, device 120 sends a second IPv6 data packet 160 including a TCP (synchronization acknowledgement) SYN-ACK segment 161 to device 110, wherein the destination IP address of the second IPv6 data packet is the IP address of device 110. The second IPv6 data packet also includes a destination extension header 162, which carries information indicating that each router on the upstream connection meets the class-based QoS requirements 154 corresponding to the specified class. In one example, the information may include a first establishment state 155 and a second establishment state 156. The destination extension header 162 may be between the TCP SYN-ACK segment 161 and the IPv6 header 163. In some embodiments, the destination extension header 162 may be considered to be part of the IPv6 header 163. In some embodiments, the destination extension header in the IPv6 data packet only needs to be checked by one or more destination nodes. An example of the destination extension header may be a destination options header defined in RFC 2460. The destination options header is used to carry optional information that only needs to be checked by one or more destination nodes of the data packet. The destination options header is identified by the Next Header field with a value of 60 in the previous header. The format of the destination options header is the same as shown in Table 1, including the fields "Next Header", "Hdr Ext Len" and "Options".

[0066] The Next Header of the Destination Options Header is an 8-bit selector that identifies the type of header that immediately follows the Destination Options Header. The Next Header uses the same value as the IPv4 Protocol field [RFC-1700 et seq]. Hdr Ext Len is an 8-bit unsigned integer indicating the length of the Destination Options Header in units of 8 octets, excluding the first 8 octets. Options is a variable-length field such that the length of the complete Destination Options Header is an integer multiple of 8 octets. Options includes one or more TLV-encoded options.

[0067] In operation 280, the device 110 receives the second IPv6 data packet 160 and obtains information indicating that each router on the upstream connection meets the class-based QoS requirement 154 from the destination extension header 162. Based on the information indicating that each router on the upstream connection meets the class-based QoS requirement 154 corresponding to the specified class, the device 110 determines that the upstream connection meets the class-based QoS requirement 154 corresponding to the specified class.

[0068] In operation 290, in order to complete the three-way handshake defined in TCP, the device 110 further sends a third IPv6 data packet 170 including a TCP acknowledgment (ACK) 171 to the device 120. Then, an uplink connection with QoS guarantee is established.

[0069] Figure 3 A method for checking the status of a connection with differentiated QoS guarantee through in-band signaling during data communication provided by an embodiment of the present invention is shown. For example, Figure 3 The method in can be used to check Figure 2 An upstream connection is shown established with end-to-end class based QoS requirements.

[0070] In operation 310, the device 110 may send an IPv6 data packet of an uplink connection (e.g., a connection established according to operations 210 to 290) to the device 140 after the uplink connection is established. Similar to the first IPv6 data packet 150, some or each of the IPv6 data packets includes a hop-by-hop extension header. The IPv6 data packet 180 in the IPv6 data packet sent by the device 110 includes a data payload 181, a hop-by-hop extension header 182 carrying a class-based QoS requirement 154, and an IPv6 header 183. The hop-by-hop extension header 182 may be a hop-by-hop option header defined in RFC 2460. The data payload 181 may be a TCP data segment including video and audio, etc.

[0071] In operation 320, the router 130 receives the IPv6 packet 180 in the IPv6 packet and determines whether the router 130 meets the class-based QoS requirements 154 (e.g., delay requirements and / or bandwidth requirements corresponding to different classes, for example, implemented by a traffic shaping scheme). When the router 130 meets the class-based QoS requirements 154, the first forwarding state 184 is set (e.g., updated) by the router 130 to indicate that the router 130 meets the class-based QoS requirements 154. When the router 130 does not meet the class-based QoS requirements 154, the first forwarding state 184 is set (e.g., updated) by the router 130 to indicate that the router 130 does not meet the class-based QoS requirements 154.

[0072] In operation 330, the router 130 sends the modified IPv6 data packet 180 to the router 140. When the router 130 meets the class-based QoS requirement 154, the router 130 sends the modified IPv6 data packet 180 (with QoS guarantee) to the router 140 according to the class-based QoS requirement 154. When the router 130 does not meet the class-based QoS requirement 154, the router 130 sends the modified IPv6 data packet 180 (without QoS guarantee) to the router 140. In some embodiments, when the router 130 does not meet the class-based QoS requirement 154, the router 130 may even stop sending the modified IPv6 data packet 180 to the router 140.

[0073] In operation 340, the router 140 receives the IPv6 data packet 180 of the upstream connection from the router 130, and the router 140 determines whether the router 140 meets the class-based QoS requirement 154. In addition, the router 140 modifies the IPv6 data packet 180 by setting the second forwarding state 185 in the hop-by-hop extension header 182. An example of the hop-by-hop extension header 182 may be a hop-by-hop options header defined in RFC2460. When the router 140 meets the class-based QoS requirement 154, the second forwarding state 185 indicates that the router 140 meets the class-based QoS requirement 154. When the router 140 does not meet the class-based QoS requirement 154, the second forwarding state 185 indicates that the router 140 does not meet the class-based QoS requirement 154.

[0074] In operation 350, the router 140 sends the IPv6 packet 180 modified by the router 140 to the device 120. When the router 140 meets the class-based QoS requirement 154, the router 140 sends the modified IPv6 packet 180 (with QoS guarantee) to the device 120 according to the class-based QoS requirement 154. When the router 140 does not meet the class-based QoS requirement 154, the router 140 sends the modified IPv6 packet 180 (without QoS guarantee) to the device 120.

[0075] In operation 360 , the device 120 receives the IPv6 data packet 180 from the router 140 and obtains the first forwarding state 184 and the second forwarding state 185 from the hop-by-hop extension header 182 .

[0076] In operation 370, device 120 sends IPv6 data packet 190 including TCP ACK 191 to device 110, wherein IPv6 data packet 190 includes first forwarding state 184 and second forwarding state 185 in destination extension header 192 between TCP ACK 191 and IPv6 header 193. IPv6 data packet 190 may be sent to device 110 via router 140 and router 130 or via other routers. Other routers may include only one of router 130 and router 140, or may not include router 130 and router 140.

[0077] In operation 380, the device 110 receives the IPv6 data packet 190 including the TCP ACK 191, and obtains the first forwarding state 184 and the second forwarding state 185 from the destination extension header 192. Therefore, the device 110 determines whether the uplink connection meets the class-based QoS requirement 154. If the uplink connection meets the class-based QoS requirement 154, the device 110 can continue the uplink connection with QoS guarantees (e.g., including end-to-end service differentiation). If the uplink connection does not meet the class-based QoS requirement 154, the device 110 can stop the uplink connection or continue the uplink connection, but does not expect the uplink connection to meet the class-based QoS requirement 154.

[0078] In some embodiments, the IPv6 data packet 150 does not include the TCP SYN 151, but includes a UDP segment. The UDP segment encapsulates information set by the application layer (layer 7) of the Open Systems Interconnection (OSI) model. This information is used to request the establishment of an uplink connection from the device 110 to the device 120. After the device 120 receives the IPv6 data packet 150, the application layer of the device 120 obtains the information, and therefore sends the IPv6 data packet 160 to promote the establishment of the uplink connection. In the IPv6 data packet 160, the TCP SYN-ACK 161 is replaced by a UDP segment, and the UDP segment includes information set by the application layer, which is used to establish the uplink connection. After the uplink connection is established, the data payload 181 in the IPv6 data packet 180 can be a UDP data segment. In addition, in the IPv6 data packet 190, the TCPACK 191 is replaced by a UDP segment.

[0079] Figure 4 A method of establishing a connection with end-to-end class-based QoS guarantees through in-band signaling is shown. Figure 2 The examples in FIG. 1 generally relate to end-to-end class-based QoS corresponding to uplink communication from device 110 to device 120, but Figure 4The examples in generally relate to end-to-end class-based QoS corresponding to downlink communications from device 120 to device 110 .

[0080] In operation 410, device 110 sends IPv6 data packet 510 including TCP SYN 511 to device 120. The destination IPv6 address of the first IPv6 data packet is the IPv6 address of device 120. IPv6 data packet 510 also includes a destination extension header 512 and an IPv6 header 513. The destination extension header 512 includes a class-based QoS requirement 514 corresponding to the downlink connection from device 120 to device 110. According to the standard definition, the destination extension header 512 only needs to be checked by one or more destination nodes of the IPv6 data packet. In the present embodiment, the destination extension header 512 only needs to be checked by device 120. Therefore, intermediate nodes such as routers 130 and routers 140 will not change or delete the class-based QoS requirement 514 included in the destination extension header. Class-based QoS requirement 514 includes the values ​​of some parameters of the downlink QoS path. These parameters can include information associated with the QoS of the downlink path, such as one or more of bandwidth, burst and delay.

[0081] In operation 420, the device 120 receives an IPv6 data packet 510, and the device 120 obtains a class-based QoS requirement 514 corresponding to the downlink connection. The QoS requirement 514 may include different QoS requirements for different classes of data packets.

[0082] In operation 430, device 120 sends an IPv6 data packet 520 including a TCP SYN-ACK segment 521 to device 110. The destination IP address of IPv6 data packet 520 is the IPv6 address of device 110. IPv6 data packet 520 also includes a hop-by-hop extension header 522, for example, an IPv6 header 523 and a hop-by-hop options header defined in RFC 2460. According to the standard definition, hop-by-hop extension header 522 needs to be checked by each router and device that forwards IPv6 data packets. Hop-by-hop extension header 522 includes a class-based QoS requirement 514′ corresponding to the downlink connection. Class-based QoS requirement 514′ is a requirement determined by device 120 based on class-based QoS requirement 514 and network resource conditions. For example, class-based QoS requirement 514′ may be exactly the same as class-based QoS requirement 514, or may be substantially the same as or close to class-based QoS requirement 514.

[0083] In operation 440, the router 140 receives the IPv6 packet 520 and determines whether the router 140 meets the class-based QoS requirement 514′. For example, the router 140 determines whether it can be configured to meet the state of the class-based QoS requirement 514′ corresponding to each class in the hop-by-hop extension header 522. When the router 140 can be configured to meet the state of the class-based QoS requirement 514′, the router 140 configures some hardware according to the class-based QoS requirement 514′ and stores the mapping between the QoS configuration state and the downstream connection. The router 140 can modify the IPv6 packet 520 by setting the establishment state 525 in the hop-by-hop extension header 522 to indicate that the router 140 has been configured to meet the class-based QoS requirement 514′. Setting the establishment state 525 can refer to updating the establishment state 525 that already exists in the hop-by-hop extension header 522, or adding the establishment state 525 to the hop-by-hop extension header 522. In some embodiments, the establishment state 525 can be located in the first establishment state field in the hop-by-hop extension header 522. When the router 140 is not configured to meet the state of the class-based QoS requirement 514′ or the configuration fails, the router 140 sets the establishment state 525 in the hop-by-hop extension header 522 to indicate that the router 140 has not been configured to meet the class-based QoS requirement. When the router 140 is configured to meet the state of the class-based QoS requirement 514′, the establishment state 525 may also include first forwarding information. The first forwarding information may include data of a limited size (mapping index) used as a reference to the QoS configuration database. By using the forwarding information in the IP data forwarding procedure by the router 140, the router 140 can quickly retrieve more detailed content of the QoS configuration state, such as the classification ID, scheduler ID, queue ID, etc., to speed up IP forwarding (e.g., forwarding connected IPv6 data packets) while ensuring quality.

[0084] In operation 450 , router 140 sends the modified IPv6 data packet 520 to router 130 .

[0085] In operation 460, the router 130 receives an IPv6 packet 520 from the router 130 and determines whether the router 130 can meet (is configured to meet) the state of the class-based QoS requirements 514' corresponding to the specified packets of multiple classes in the hop-by-hop extension header 522. When the router 130 can be configured to meet the class-based QoS requirements 514', the router 130 configures some hardware according to the parameters of the class-based QoS requirements 514' and stores the mapping between the QoS configuration state and the downstream connection. The router 130 can also modify the IPv6 packet 520 by setting the establishment state 526 in the hop-by-hop extension header 522 to indicate that the router 130 has been configured to meet the class-based QoS requirements. Setting the establishment state 526 in the hop-by-hop extension header 522 can refer to updating the establishment state 526 in the hop-by-hop extension header 522 or adding the establishment state 526 to the hop-by-hop extension header 522. The establishment state 526 can be included in the second establishment state field. When the router 130 is configured to meet the state of the class-based QoS requirement 514′, the establishment state 526 may also include second forwarding information. The second forwarding information may include data of a limited size (mapping index) used as a reference to the QoS configuration database. When the router 130 is not configured to meet the state of the class-based QoS requirement 514′ or the configuration fails, the router 130 modifies the IPv6 data packet 520 by setting the establishment state 526 to indicate that the router 130 has not been configured to meet the class-based QoS requirement 514′. In some embodiments, the first establishment state field and the second establishment state field refer to the same field in the hop-by-hop extension header that includes two or more establishment states. In some embodiments, the first establishment state field and the second establishment state field are two different fields in the hop-by-hop extension header 522.

[0086] In operation 470 , the router 130 sends the IPv6 data packet 520 modified by the router 130 to the device 110 .

[0087] In operation 480 , the device 110 receives the IPv6 data packet 520 and obtains the setup state 525 and the setup state 526 from the hop-by-hop extension header 522 .

[0088] In operation 490, after device 110 determines that establishment state 525 and establishment state 526 indicate that router 130 and router 140 meet class-based QoS requirements 514′, device 110 may send an IPv6 packet 530 including a TCP ACK 531 to device 120. After TCP ACK 531 is received by device 120, the TCP three-way handshake is completed, and a connection (TCP connection) with differentiated QoS guarantees from device 120 to device 110 is established.

[0089] In the event that the establishment state 525 and the establishment state 526 indicate that one or more routers 130 and 140 do not meet the class-based QoS requirement 514', the device 110 may have different options. For example, the device 110 may send an IPv6 data packet 530 to the device 120 to establish a downstream connection without a class-based QoS guarantee (e.g., services that do not distinguish between classes). For another example, the device 110 may stop establishing a downstream connection with the device 120 and begin to check why some routers do not meet the class-based QoS requirement 514'. For another example, the device 110 may adjust the class-based QoS requirement 514' and initiate a new procedure to establish a new downstream connection with a QoS guarantee according to the adjusted class-based QoS requirement.

[0090] Figure 5 A method for checking the status of a connection with a class-based QoS guarantee by in-band signaling during data communication according to an embodiment of the present invention is shown. Figure 3 The examples in generally involve checking the transmission of device 110 to device 120 (e.g., Figure 2 The end-to-end class-based QoS corresponding to the uplink communication established as shown Figure 5 The examples in generally involve checking the communication between device 120 and device 110 (e.g., Figure 4 End-to-end class-based QoS corresponding to the downlink communication established as shown.

[0091] In operation 610, after a downlink connection (with QoS guarantee) that meets the class-based QoS requirements (e.g., a connection established according to operations 410 to 490) is established, device 120 may send an IPv6 data packet of the downlink connection to device 110. Each data packet includes a TCP data segment. An IPv6 data packet 540 in the IPv6 data packet sent by device 120 includes a data payload 541, a hop-by-hop extension header 542, and an IPv6 header 543. The data payload 541 may be a TCP data segment including video and audio.

[0092] In some embodiments, hop-by-hop extension header 542 includes forwarding state 544 , which includes first forwarding information in setup state 525 and second forwarding information in setup state 526 .

[0093] In some other embodiments, the hop-by-hop extension header 542 does not include the first forwarding information and the second forwarding information. Then, the router receiving the IPv6 data packet 540 determines whether the IPv6 data packet 540 belongs to a downlink connection based on the 5-tuple of the IPv6 data packet 540. The 5-tuple includes the source IP address, source port number, destination IP address, destination port number and transport protocol number or identifier of the IPv6 data packet 540. The source IP address, destination IP address and transport protocol number or identifier can be carried in the IPv6 header 543; the source port number and the destination port number can be carried in the TCP header in the data payload 541. After determining that the IPv6 data packet 540 belongs to a downlink connection, the router forwards the IPv6 data packet 540 according to the forwarding state mapped to the downlink connection, wherein the forwarding according to the forwarding state satisfies the class-based QoS requirements corresponding to the downlink connection.

[0094] In operation 620, the router 140 receives the IPv6 packet 540 and determines whether the router 140 meets the class-based QoS requirement corresponding to the downstream connection, such as the class-based QoS requirement 514′. When the router 140 meets the class-based QoS requirement, the first forwarding state 545 is modified (e.g., updated) by the router 140 to indicate that the router 140 meets the class-based QoS requirement. When the router 140 does not meet the class-based QoS requirement, the first forwarding state 545 is modified (e.g., updated) by the router 140 to indicate that the router 140 does not meet the class-based QoS requirement 514′. In one example, when the hop-by-hop extension header 542 includes the first forwarding information, the router 140 determines whether it has a configured forwarding state mapped to the first forwarding information. If the router 140 has a configured forwarding state, the router 140 meets the class-based QoS requirement. In another example, when the router 140 has a forwarding state mapped to the downstream connection to which the IPv6 packet 540 belongs, the router 140 meets the class-based QoS requirement.

[0095] In operation 630, router 140 sends the modified IPv6 packet 540 to router 130. When router 140 meets the class-based QoS requirement, router 140 sends the modified IPv6 packet 540 to router 130 according to the class-based QoS requirement (e.g., using traffic shaping configured according to the traffic shaping parameters). When router 140 does not meet the class-based QoS requirement, router 140 sends the modified IPv6 packet 540 (without the class-based QoS) to router 130. In some embodiments, router 140 may even stop sending the modified IPv6 packet 540 to router 130 when router 140 does not meet the class-based QoS requirement.

[0096] In operation 640, after the router 130 receives the IPv6 data packet 540 of the downstream connection from the router 140, the router 130 determines whether the router 130 meets the class-based QoS requirement 514′. In addition, the router 130 modifies the IPv6 data packet 540 by setting the second forwarding state 546 in the hop-by-hop extension header 542. When the router 130 meets the class-based QoS requirement, the second forwarding state 546 indicates that the router 130 meets the class-based QoS requirement. When the router 130 does not meet the class-based QoS requirement, the second forwarding state 546 indicates that the router 130 does not meet the class-based QoS requirement. In operation 650, the router 130 sends the IPv6 data packet 540 modified by the router 130 to the device 110. When the router 130 meets the class-based QoS requirement, the router 130 sends the modified IPv6 data packet 540 to the device 120 according to the class-based QoS requirement.

[0097] In operation 660 , the device 110 receives the IPv6 data packet 540 from the router 130 , and obtains the first forwarding state 545 and the second forwarding state 546 from the hop-by-hop extension header 542 .

[0098] In operation 670, device 110 sends IPv6 data packet 550 including TCP ACK 551 to device 120. IPv6 data packet 550 also includes first forwarding state 545 and second forwarding state 546 in destination extension header 552 between TCP ACK 551 and IPv6 header 553. IPv6 data packet 550 may be sent to device 120 via router 130 and router 140 or via other routers. Other routers may include only one of router 130 and router 140, or may not include router 130 and router 140.

[0099] In operation 680, the device 120 receives the IPv6 data packet 550 including the TCP ACK 55, and thus determines whether the downlink connection meets the class-based QoS requirement based on the first forwarding state 545 and the second forwarding state 546. In one example, when both the router 130 and the router 140 meet the class-based QoS requirement, the downlink connection meets the class-based QoS requirement; otherwise, the downlink connection does not meet the class-based QoS requirement. If the downlink connection meets the class-based QoS requirement, the device 120 may continue the downlink connection. If the downlink connection does not meet the class-based QoS requirement, the device 120 may stop the downlink connection or continue the downlink connection, but does not expect the downlink connection to meet the class-based QoS requirement 154.

[0100] After the downstream connection is established, the data payload 541 in the IPv6 data packet 540 may be a UDP data segment. In addition, in the IPv6 data packet 550, the TCP ACK 551 is replaced by a UDP segment.

[0101] Figure 6 A method for establishing a connection with class-based QoS through in-band signaling provided by an embodiment of the present invention is shown. For example, Figure 6 The method in may be used to establish a connection with end-to-end class-based QoS requirements corresponding to uplink communication and downlink communication between the device 110 and the device 120 .

[0102] In operation 705, device 110 sends an IPv6 data packet 810 including a TCP SYN segment 811 to router 130. IPv6 data packet 810 is used to establish a connection from device 110 to device 120, and the destination IPv6 address of IPv6 data packet 810 is the IPv6 address of device 120. IPv6 data packet 810 also includes a hop-by-hop extension header 812. Hop-by-hop extension header 812 may be between IPv6 header 813 and TCP SYN segment 811, and carries a class-based QoS requirement 814 corresponding to an upstream connection (e.g., a traffic shaping parameter for implementing a class-based traffic shaping scheme). The upstream connection refers to a connection from device 110 to device 120. Hop-by-hop extension header 812 may be a hop-by-hop extension header defined in RFC 2460. According to RFC 2460, any IPv6 data packet including hop-by-hop extension header 812 needs to be checked by each router receiving the IPv6 data packet (e.g., all routers, devices 110, and devices 120 on the connection). The class-based QoS requirement 814 includes values ​​of some parameters of the upstream connection. These parameters may include information associated with the QoS of the upstream connection, such as one or more of bandwidth, burst, and latency for one or more classes of packets. The class-based QoS requirement 814 may indicate that the IPv6 packet 810 is used to establish an upstream connection with a class-based QoS guarantee. For example, the bandwidth of the upstream connection with the QoS guarantee is not less than the value included in the class-based QoS requirement.

[0103] In operation 710, the router 130 receives the IPv6 packet 810 and obtains the class-based QoS requirement 814 in the hop-by-hop extension header 812. The router 130 determines whether its ability to forward packets of the upstream connection meets the class-based QoS requirement 814. If the ability meets the class-based QoS requirement 814, the router 130 configures its hardware according to the class-based QoS requirement so that the router 130 forwards packets of the upstream connection according to the class-based QoS requirement 814 (e.g., configures a traffic shaper according to the traffic shaping parameters 814 of the QoS requirement). The router 130 may also modify the IPv6 packet 810 by setting first information in the hop-by-hop extension header 812 of the IPv6 packet 810, wherein the first information indicates that the router meets the first QoS requirement. For example, the router 130 may update a first setup state 815 in the hop-by-hop extension header 812 to indicate that the router 130 meets the class-based QoS requirement, wherein the setup state 815 is located in a first setup state field in the hop-by-hop extension header 812. If the router 130 does not meet the class-based QoS requirement, the router 130 updates the first setup state 815 in the hop-by-hop extension header 812 to indicate that the router 130 does not meet the class-based QoS requirement.

[0104] In operation 715 , the router 130 sends the modified IPv6 data packet 810 to the router 140 according to the destination IP address of the IPv6 data packet 810 .

[0105] In operation 720, the router 140 receives the IPv6 packet 810 from the router 130 and obtains the class-based QoS requirement 814 in the hop-by-hop extension header 812. Similar to the router 130, the router 140 determines whether its ability to forward packets of the upstream connection meets the class-based QoS requirement 814. If the ability of the router 140 meets the class-based QoS requirement 814, the router 140 configures its hardware according to the class-based QoS requirement so that the router 140 forwards the packets of the upstream connection according to the class-based QoS requirement 814 (e.g., using a traffic shaping scheme configured according to the traffic shaping parameters of the QoS requirement 814). The router 140 may also modify the IPv6 packet 810 by setting second information in the hop-by-hop extension header 812 of the IPv6 packet 810, wherein the second information indicates that the router 140 meets the class-based QoS requirement 814. For example, router 140 may update a second setup state 816 in the hop-by-hop extension header to indicate that router 140 meets the class-based QoS requirement 814, wherein the second setup state 816 is located in a second setup state field in the hop-by-hop extension header. If router 140 does not meet the class-based QoS requirement 814, router 140 updates the setup state in the hop-by-hop extension header 812 to indicate that router 140 does not meet the class-based QoS requirement 814. In some embodiments, the first setup state field and the second setup state field are two different fields in the hop-by-hop extension header. In some embodiments, the first setup state field and the second setup state field refer to the same field in the hop-by-hop extension header 812 that includes two or more setup states.

[0106] In operation 725 , the router 140 sends the IPv6 data packet 810 modified by the router 140 to the device 120 according to the destination IP address of the IPv6 data packet 810 .

[0107] In operation 730 , the device 120 receives an IPv6 packet 810 from the router 140 , and determines 814 that each router on the upstream connection meets the class-based QoS requirement based on the first information and the second information in the hop-by-hop extension header.

[0108] In operation 735, device 120 sends an IPv6 packet 820 including a TCP SYN-ACK segment 821 to device 110. The destination IP address of IPv6 packet 820 may be the IP address of device 110. IPv6 packet 820 also includes a destination extension header 822, which carries third information (e.g., first establishment state 155) indicating that router 130 meets QoS requirement 814 and fourth information (e.g., second establishment state 156) indicating that router 140 meets QoS requirement 814. Destination extension header 822 may be between TCP SYN-ACK segment 821 and IPv6 header 823. In addition, IPv6 packet 820 includes a hop-by-hop extension header 824. Hop-by-hop extension header 824 includes a class-based QoS requirement 825 corresponding to the downstream connection from device 120 to device 110. IPv6 packet 820 is sent according to its destination IP address.

[0109] In operation 740, the router 141 receives the IPv6 packet 820 and obtains the class-based QoS requirement 825 (e.g., traffic shaping parameters) in the hop-by-hop extension header 824. The router 141 determines whether its ability to forward packets of the downstream connection meets the class-based QoS requirement 825. If its ability meets the class-based QoS requirement 825, the router 141 forwards the packets of the downstream connection according to the class-based QoS requirement 825. The router 141 may also modify the IPv6 packet 820 by setting the hop-by-hop extension header 824 in the IPv6 packet 820 to indicate that the router 141 meets the class-based QoS requirement 825. If the router 141 does not meet the class-based QoS requirement 825, the router 141 sets the hop-by-hop extension header 824 to indicate that the router 130 does not meet the class-based QoS requirement. In some embodiments, the above setting may refer to setting the establishment state 826 in the hop-by-hop extension header 824.

[0110] In operation 745 , the router 141 sends the IPv6 data packet 820 modified by the router 141 to the router 131 according to the destination IP address of the IPv6 data packet 820 .

[0111] In operation 750, the router 131 receives the IPv6 packet 820 and obtains the class-based QoS requirement 825 in the hop-by-hop extension header 824. The router 131 determines whether its ability to forward packets of the downstream connection meets the class-based QoS requirement 825. If its ability meets the class-based QoS requirement 825, the router 131 forwards the packets of the downstream connection according to the class-based QoS requirement 825. The router 131 may also modify the IPv6 packet 820 by setting the hop-by-hop extension header 824 in the IPv6 packet 820 to indicate that the router 131 meets the class-based QoS requirement 825. If the router 131 does not meet the class-based QoS requirement 825, the router 141 sets the hop-by-hop extension header 824 to indicate that the router 130 does not meet the class-based QoS requirement. In some embodiments, the above setting may refer to setting the establishment state in the hop-by-hop extension header 824.

[0112] In operation 755 , the router 131 sends the IPv6 data packet 820 modified by the router 131 to the device 110 .

[0113] In operation 760, the device 110 obtains the third information and the fourth information from the destination extension header 822. Based on the obtained information, the router 131 determines that all routers on the uplink connection meet the class-based QoS requirement. Therefore, if the three-way handshake is completed, the uplink connection can be established. In addition, based on the hop-by-hop extension header 824, the device 110 can determine whether all routers on the downlink connection meet the class-based QoS requirement 825.

[0114] In operation 765, device 110 sends an IPv6 data packet 830 including a TCP ACK segment 831 to device 120. IPv6 data packet 830 is sent after device 110 determines that all routers on the downstream connection meet the class-based QoS requirement 825. Therefore, IPv6 data packet 830 includes a destination extension header 832 between TCP ACK segment 831 and IPv6 header 833, wherein the destination extension header 832 is set to indicate that all routers on the downstream connection meet the class-based QoS requirement 825. For example, the destination extension header 832 is set to indicate that router 131 and router 141 meet the class-based QoS requirement 825.

[0115] In operation 770, device 120 receives IPv6 data packet 830 from device 110. TCP ACK segment 831 indicates that an uplink connection with class-based QoS is established. In addition, destination extension header 832 indicates that a downlink connection with class-based QoS is also established. Although in this example, the uplink connection and the downlink connection pass through different network devices (the uplink connection passes through router 130 and router 140, and the downlink connection passes through router 141 and router 131), this method can also be used in the case where the uplink connection and the downlink connection use the same router (for example, the downlink connection passes through router 140 and the downlink connection of router 130 as the uplink connection).

[0116] Figure 7 A method of checking the status of a connection with class-based QoS through in-band signaling during data communication according to one embodiment of the present invention is shown. Figure 7 The examples in generally involve checking the connection between device 120 and device 110 (e.g., Figure 6 End-to-end class-based QoS corresponding to uplink communication and downlink communication) established as shown.

[0117] After the uplink connection from device 110 to device 120 via router 130 and router 140 and the downlink connection from device 120 to device 110 via router 141 and router 131 are established, device 110 and device 120 may transmit data via the connection. During data transmission, the status of the two connections may be checked.

[0118] In operation 905 , the router 110 sends an IPv6 data packet 840 for an upstream connection to the router 120 . The IPv6 data packet 840 includes a TCP data segment 841 , a hop-by-hop extension header 842 , and an IPv6 header 843 , wherein the hop-by-hop extension header 842 includes the class-based QoS requirement 814 .

[0119] In operation 910, the router 130 receives the IPv6 packet 840 and determines whether the router 130 meets the class-based QoS requirement 814. When the router 130 meets the class-based QoS requirement 814, the hop-by-hop extension header 842 is modified to indicate that the router 130 meets the class-based QoS requirement 814. When the router 130 does not meet the class-based QoS requirement 814, the hop-by-hop extension header 842 is modified to indicate that the router 130 does not meet the class-based QoS requirement 814.

[0120] In operation 915 , the router 130 sends the IPv6 data packet 840 modified by the router 130 to the router 140 .

[0121] In operation 920, the router 140 receives the IPv6 data packet 840 and determines whether the router 140 meets the class-based QoS requirement 814. When the router 140 meets the class-based QoS requirement 814, the hop-by-hop extension header 842 is modified to indicate that the router 140 meets the class-based QoS requirement 814. When the router 140 does not meet the class-based QoS requirement 814, the hop-by-hop extension header 842 is modified to indicate that the router 140 does not meet the class-based QoS requirement 814.

[0122] In operation 925 , the router 140 sends the IPv6 data packet 840 modified by the router 140 to the device 120 .

[0123] In operation 930 , the device 120 receives the IPv6 data packet 840 from the router 140 , and determines based on the first information and the second information in the hop-by-hop extension header 842 that each router on the upstream connection meets the class-based QoS requirement 814 .

[0124] In operation 935, device 120 sends IPv6 data packet 850 to device 110. sIPv6 data packet 850 includes TCP data segment 851, hop-by-hop extension header 852, destination extension header 853, and IPv6 header 854. Destination extension header 853 is set to indicate whether all routers on the upstream connection meet class-based QoS requirement 814. Hop-by-hop extension header 852 includes class-based QoS requirement 825.

[0125] In operation 940, the router 141 receives the IPv6 data packet 850 and determines whether the router 141 meets the class-based QoS requirement 825. When the router 141 meets the class-based QoS requirement 825, the hop-by-hop extension header 852 is modified to indicate that the router 141 meets the class-based QoS requirement 825. When the router 141 does not meet the class-based QoS requirement 825, the hop-by-hop extension header 852 is modified to indicate that the router 141 does not meet the class-based QoS requirement 825.

[0126] In operation 945 , the router 141 sends the IPv6 data packet 850 modified by the router 141 to the router 131 .

[0127] In operation 950, the router 131 determines whether the router 131 meets the class-based QoS requirement 825. When the router 131 meets the class-based QoS requirement 825, the hop-by-hop extension header 852 is modified to indicate that the router 131 meets the class-based QoS requirement 825. When the router 131 does not meet the class-based QoS requirement 825, the hop-by-hop extension header 852 is modified to indicate that the router 131 does not meet the class-based QoS requirement 825.

[0128] In operation 955 , the router 131 sends the IPv6 data packet 850 modified by the router 131 to the device 110 .

[0129] In operation 957 , the device 110 determines whether the uplink connection satisfies the class-based QoS requirement 814 according to the destination extension header 853 .

[0130] In operation 960, device 110 sends IPv6 packet 860 including TCP ACK 861 to device 120. IPv6 packet 860 also includes destination extension header 862 and IPv6 header 863, wherein destination extension header 862 is set to indicate whether all routers on the downstream connection meet class-based QoS requirement 825.

[0131] In operation 965 , the device 120 receives the IPv6 packet 860 and determines whether the downstream connection meets the class-based QoS requirement 825 .

[0132] When the network is used for end-to-end differentiated services (e.g., through in-band signaling described in any of the above examples or otherwise), data packets can be managed differently according to their categories (e.g., a router can manage different categories of data packets differently through different queuing methods or other methods of data packets). Data packets can be divided into different categories and can be identified accordingly in various ways. For example, an IPv6 data packet includes a Differentiated Services Code Point (DSCP) field in the IPv6 header, which can be used to indicate which category the data packet belongs to. According to various aspects of the current technology, the DSCP value of the data packet can be selected at the ingress router of the network. The appropriate DSCP value can be selected from a list of DSCP values ​​that conform to the standard (e.g., provided in IETF RFC 4594, the entire contents of IETF RFC 4594 are incorporated by reference in this application) or selected by other means. In some embodiments, one or more DSCP values ​​that are not part of the standard can be used. For example, a first DSCP value according to the current technology (which may or may not be listed in IETF RFC 4594) can indicate a delay guaranteed service (Latency Guaranteed Service, LGS). A second DSCP value according to the current technology (which may or may not be listed in IETF RFC 4594) may indicate a Bandwidth Guaranteed Service (BGS). A third DSCP value according to the current technology (which may or may not be listed in IETF RFC 4594) may indicate a Best Efforts Service (BES). Various aspects of the current technology may be implemented using one or more of these DSCP values ​​or other values ​​(e.g., using only the DSCP values ​​in IETF RFC 4594 or using some other system that indicates the class to which the packet belongs).

[0133] Figure 8An example is shown in which device 110 operates as an ingress router of network 100 to classify packets according to a classification scheme including at least three categories (e.g., LGS, BGS, and BES). In operation 1000, device 110 classifies packets by setting appropriate DSCP values ​​in the IPv6 header of the packets. Packets 1004, 1006, and 1008 are classified. Packets 1004, 1006, and 1008 all include headers 1010 and payloads 1012, and each packet includes a different DSCP value in its header. For example, device 110 classifies packet 1004 as an LGS packet and sets an LGS DSCP value 1014 in the header 1010 of packet 1004. Device 110 classifies packet 1006 as a BGS packet and sets a BGS DSCP value 1016 in the header 1010 of packet 1006. Device 110 classifies data packet 1008 as a BES data packet and sets a BES DSCP value 1018 in header 1010 of data packet 1008 .

[0134] In operation 1002 , data packets 1004 , 1006 , and 1008 are sent from device 110 to router 130 .

[0135] In operation 1020, router 130 receives data packets 1004, 1006, and 1008, and reads a header including a corresponding DSCP value in each data packet (e.g., parses the data packet to identify the header). These DSCP values ​​indicate the category of data packets 1004, 1006, and 1008. Router 130 processes these data packets according to the category of data packets 1004, 1006, and 1008 (e.g., according to a traffic shaping scheme that implements differentiated services configured by traffic shaping parameters). For example, after reading the LGS DSCP value 1014 in the header 1010 of data packet 1004, router 130 can prioritize data packet 1004 (e.g., place it in a dedicated queue). After taking the BGSDSCP value 1016 in the header 1010 of data packet 1006, router 130 can set the priority of data packet 1006 to be lower than the priority of data packet 1004 (e.g., place it in a different queue with a lower priority). After reading the BES DSCP value 1018 in the header 1010 of the data packet 1008, the router 130 may set the data packet 1008 to a lowest priority (which may be a default priority) and may place it in a low priority queue.

[0136] In operation 1022 , data packets 1004 , 1006 , and 1008 are sent from router 130 to router 140 .

[0137] In operation 1024, router 140 receives data packets 1004, 1006, and 1008, and reads a header including a corresponding DSCP value in each data packet (e.g., parses the data packet to obtain the header). These DSCP values ​​indicate the category of data packets 1004, 1006, and 1008. Router 140 processes these data packets according to the category of data packets 1004, 1006, and 1008 (e.g., according to a traffic shaping scheme that implements differentiated services configured by traffic shaping parameters). For example, after reading the LGS DSCP value 1014 in the header 1010 of data packet 1004, router 140 can prioritize data packet 1004 (e.g., place it in a dedicated queue). After taking the BGSDSCP value 1016 in the header 1010 of data packet 1006, router 140 can set the priority of data packet 1006 to be lower than the priority of data packet 1004 (e.g., place it in a different queue with a lower priority). After reading the BES DSCP value 1018 in the header 1010 of the data packet 1008, the router 140 may set the priority of the data packet 1008 to be the lowest (which may be a default priority) and may place it in a low priority queue.

[0138] In operation 1026 , data packets 1004 , 1006 , and 1008 are sent from router 140 to device 120 .

[0139] In operation 1028, the device 120 receives the data packets 1004, 1006, and 1008 and reads the header of each data packet including the corresponding DSCP value. These DSCP values ​​indicate the category of the data packets 1004, 1006, and 1008. The device 120 processes the data packets 1004, 1006, and 1008 according to the category of the data packets (e.g., according to the previously configured differentiated services). For example, after reading the LGS DSCP value 1014 in the header 1010 of the data packet 1004, the router 140 can prioritize the data packet 1004 (e.g., place it in a dedicated queue). After taking the BGS DSCP value 1016 in the header 1010 of the data packet 1006, the router 140 can set the priority of the data packet 1006 to be lower than the priority of the data packet 1004 (e.g., place it in a different queue with a lower priority). After reading the BES DSCP value 1018 in the header 1010 of the data packet 1008, the router 140 may set the data packet 1008 to have the lowest priority (which may be a default priority) and may place it in a low priority queue. In this example, the device 120 is configured as an egress device, and the data packets 1004, 1006, and 1008 may be sent out of the network 100 through the device 120. It should be understood that since different data packets are processed differently at each step through network 100, data packet 1004 can be sent from device 110 to device 120 quickly through network 100 (meeting the guaranteed delay requirement), data packet 1006 can be sent from device 110 to device 120 less quickly through network 100 (meeting the guaranteed bandwidth requirement), and data packet 1008 can be sent from device 110 to device 120 through the network at a relatively slow speed (meeting the best effort requirement), so that even if data packets 1004, data packet 1006, and data packet 1008 start from device 110 together, they can arrive at device 120 (and leave network 100) at different times.

[0140] Fig. 9A A schematic diagram of a network device 1040 provided for one embodiment of the present invention. In some embodiments, the network device 1040 may refer to a router 130 or a router 140. In some embodiments, the network device 1040 may refer to a router 131 or a router 141. In some embodiments, the network device 1040 may refer to a device 110 (e.g., configured as an ingress router of the network 100). In some embodiments, the network device 1040 may refer to a device 120 (e.g., configured as an egress router of the network 100). Fig. 9AAs shown, the network device 1040 may include a processor 1050, a memory 1060 coupled to the processor 1050, a transceiver (Tx / Rx) 1070, and a port 1080 coupled to the Tx / Rx 1070. The port 1080 is used to communicate through the network, and the port 1080 may be considered to form a network interface (which may include a physical interface for wire connection in a wired network and / or may include a physical interface for wireless communication in a wireless network). The processor 1050 may be implemented as a general-purpose processor, or may be part of one or more application specific integrated circuits (ASICs) and / or digital signal processors (DSPs). The processor 1050 may refer to a single processor or to multiple processors. The memory 1060 may include a cache for temporarily storing content, such as a random-access memory (RAM). In addition, the memory 1060 may include a long-term memory, such as a read-only memory (ROM). In one embodiment, the memory 1060 may include a plurality of software modules, such as an entry module 1061 (receiving module), a modification module 1062, and an exit module 1063 (sending module). By executing the instructions in the software modules, the processor 1050 may perform a plurality of operations. In some embodiments, when a module is used to perform an operation, it may be indicated that the processor 1050 is used to execute the instructions in the module to perform the operation. By executing the instructions in the memory 1060, the processor 1050 may perform all or part of all operations performed by one or more of the other components of the router 130, the router 140, the device 110, the device 120, and / or the network 100. The network device 1040 may refer to any device capable of routing IP packets according to their destination IP addresses.

[0141] The memory 1060 also includes a database 1066, which may include information for the configuration and operation of the network device 1040. For example, the database 1066 may include data on the class-based QoS requirements of one or more classes of packets and parameters associated with these requirements. For example, the database 1066 may include traffic shaping parameters for configuring the inlet module 1061 and the outlet module 1063 to implement one or more traffic shaping schemes to achieve the QoS required for a class of packets. The data in the database 1066 can be obtained from in-band communication information (such as the above-mentioned in-band signaling) so that the network device 1040 and any other router of the network 100 can be used to implement different QoS for packets of different classes. In this example, it is shown that the database 1066 includes 4 databases: LGS / BGS flow DB 1072, inlet shaper DB 1073, outlet shaper DB 1074 and weighted fair queuing (Weighted Fair Queuing, WFQ) DB 1075. In other examples, different numbers of databases can be used to implement various aspects of the current technology. The memory 1060 also includes a loader module 1078, which is used to load data into the database 1066 (e.g., into one or more of the LGS / BGS flow DB 1072, the ingress shaper DB 1073, the egress shaper DB 1074, and the WFQ DB 1075) based on the in-band communication. The data can be loaded to initialize the database 1066, and can be appropriately updated by loading different parameter values ​​to reflect different traffic shaping schemes. The loader module 1078 in the memory 1060, when loaded into the processor 1050, can cause the circuit of the processor 1050 to perform a database loading function (e.g., configured as a database loading circuit to obtain traffic shaping parameters from the in-band communication received by the network interface in the data packet). Therefore, an example of a database loading circuit can be a processor configured by software or firmware to perform database loading. In other examples, the database loading circuit can be a dedicated circuit, a programmable logic device (PLD), or some combination of one or more of these components.

[0142] The ingress module 1061 is used to receive a first IPv6 data packet for establishing a first connection, wherein the first IPv6 data packet includes a QoS requirement based on a first category corresponding to the first connection in a hop-by-hop extension header of the first IPv6 data packet. The modification module 1062 is used to modify the first IPv6 data packet by setting first information in the hop-by-hop extension header of the first IPv6 data packet, wherein the first information indicates that the router meets the first QoS requirement. The egress module 1063 is used to send the modified first IPv6 data packet to the second router according to the destination IP address of the modified first IPv6 data packet.

[0143] The ingress module 1061 may also be used to receive a second IPv6 data packet for establishing a first connection from a second router, wherein the second IPv6 data packet carries second information in a destination extension header of the second IPv6 data packet, and the second information indicates that a plurality of routers including the first router meet the first QoS requirement. The egress module 1063 may also be used to send the second IPv6 data packet to a next hop according to the destination IP address of the second IPv6 data packet. For example, the routing table in the network device 1040 may route the data packet from the ingress module 1061 (or an instance thereof) to the egress module 1063 (or an instance thereof) according to the destination IP address of the second IPv6 data packet.

[0144] In addition, the ingress module 1061 not only receives the data packet for establishing the connection, but also can be used to receive the data packet of the connection. For example, the ingress module 1061 is used to receive the IPv6 data packet of the first connection. Accordingly, the modification module 1062 is used to modify the IPv6 data packet by setting the third information in the hop-by-hop extension header of the IPv6 data packet, wherein the third information indicates that the modified IPv6 data packet is sent according to the first QoS requirement. The egress module 1063 is used to send the modified IPv6 data packet to the next hop according to the destination IP address of the IPv6 data packet.

[0145] In some embodiments, the first IPv6 data packet used to establish the first connection may refer to IPv6 data packet 150 , the second IPv6 data packet used to establish the first connection may refer to IPv6 data packet 160 , and the IPv6 data packet of the first connection may refer to IPv6 data packet 180 .

[0146] In some embodiments, the first IPv6 data packet used to establish the first connection may refer to IPv6 data packet 520, the second IPv6 data packet used to establish the first connection may refer to IPv6 data packet 530, and the IPv6 data packet of the first connection may refer to IPv6 data packet 540. In some embodiments, the first IPv6 data packet used to establish the first connection may refer to IPv6 data packet 810, the second IPv6 data packet used to establish the first connection may refer to IPv6 data packet 820, and the IPv6 data packet of the first connection may refer to IPv6 data packet 840.

[0147] Fig. 9B The ingress router of the network (e.g. Fig. 9A An example of how packets are processed at a network device 1040 configured as an ingress router in FIG. 1040. In this example, LGS packets can be classified in a dedicated class that can be added to a previous existing standard (e.g., a new DSCP value assigned by the Internet Assigned Numbers Authority (IANA)), or can be mapped to an EF class specified in RFC 4594 (e.g., to support backward compatibility) so that the DSCP class complies with the standard of RFC 4594 (in other examples, classes that do not comply with this standard can be used). Traffic shaping uses a single rate Three Color Marker (srTCM) scheme (e.g., as detailed in RFC2697, the entire contents of RFC2697 are incorporated by reference in this application). The srTCM scheme can be detailed according to traffic shaping parameters such as Committed Information Rate (CIR) (in bps), Committed Burst Size (CBS) and Exceeded Burst Size (EBS) (in bytes), and the corresponding values ​​(traffic shaping parameter values) can be loaded and stored in the router's database (for example, obtained through in-band signaling). Optionally, a dual-rate TCM scheme can be used (for example, the trTCM scheme detailed in RFC4115, the entire content of RFC4115 is incorporated by reference in this application). The trTCM scheme can be detailed according to CIR, Peak Information Rate (PIR), CBS and EBS. In some cases, only CIR may be required to detail the traffic shaping scheme.

[0148] The data packets received by the network device 1040 (e.g., via one of the port 1080 and Tx / Rx 1070) are sent to the ingress shaper module 1130, which can be part of the ingress module 1061 or can correspond to the ingress module 1061 configured according to the configuration information stored in the database 1066 (e.g., configured by the traffic shaping parameters stored in the database 1066). The ingress shaper module 1130 includes a classifier 1132. The classifier 1132 checks whether the data packet has in-band signaling information (e.g., the class-based QoS requirements in the hop-by-hop extension header as shown above). If the in-band signaling information is provided, the in-band signaling information is read to identify the QoS requirements. These requirements can be checked against a database (e.g., "LGS / BGS flow DB 1072" for LGS categories and BGS classes) to determine whether the required service is available (e.g., a service level agreement (SLA) can be checked to determine whether the QoS requirements meet the SLA). If the service is available, the classifier can check whether there are sufficient available resources. If resources are insufficient, in-band signaling may be updated to indicate that service is denied, and packets may be categorized accordingly. If resources are sufficient, QoS parameters may be updated in one or more databases (e.g., in one or more of the LGS / BGS flow DB 1072, ingress shaper DB 1073, egress shaper DB 1074, and / or WFQ DB 1075).

[0149] Classifier 1132 sends the data packet to the appropriate marker 1134 to marker 1139 according to the classification rules (e.g., from LGS / BGS flow DB 1072). The classification rules may include which class should be used if the intended service is denied due to admission control, resource limitations, or other reasons. Marker 1134 to marker 1139 sets the DSCP bits in the data packet header to the corresponding DSCP value. For example, the LGS marker 1134 (which may be an EF marker) sets the DSCP bit in the packet header to indicate that the packet belongs to the EF category, the AF41 marker 1135 sets the DSCP bit in the packet header to indicate that the packet belongs to the AF41 category, the AF31 marker 1136 sets the DSCP bit in the packet header to indicate that the packet belongs to the AF31 category, the AF21 marker 1137 sets the DSCP bit in the packet header to indicate that the packet belongs to the AF21 category, the AF11 marker 1138 sets the DSCP bit in the packet header to indicate that the packet belongs to the AF11 category, and the BE marker 1139 sets the DSCP bit in the packet header to indicate that the packet belongs to the BE category. The LGS packet is sent to the ingress traffic shaper 1142 (ingress shaper), which may perform traffic shaping according to a traffic shaping rule (e.g., according to an srTCM scheme, a trTCM scheme, or a leaky bucket scheme). For example, the ingress shaper 1142 can measure the LGS class rate and mark the packets with different colors according to the rules obtained from the database (e.g., the ingress shaper DB 1073). For example, the ingress shaper 1142 can be used to send certain LGS packets (green packets) to the joiner 1144, where the packets with different markings are re-joined. The ingress shaper 1142 can send certain LGS packets (yellow packets) to the AF41 marker 1135 to re-mark these LGS packets as AF41 packets. The ingress shaper 1142 can send certain LGS packets (red packets) to one or more lower priority markers (e.g., the AF31 marker 1136 as shown) to re-mark the LGS packets as lower level packets (e.g., AF31 packets). In some cases, the red packets may be discarded. The packets are sent from markers 1135 to marker 1139 to joiner 1144, where they are rejoined with the LGS packets from ingress shaper 1142 and sent to forwarding module 1146. The packets can be marked with "different colors" by a suitable code, which can be a code added to the DS field of the IP packet, as described in RFC2697 (single rate) and RFC2698 (dual rate), which describe setting the DS field of the packet to mark the color as green, yellow or red. The entire content of RFC2698 is also incorporated by reference in this application.Re-marking can replace such a code with an updated code to reflect a different color. As described in RFC2697, the "color" of a packet is a way to describe the classification of the packet, which can be achieved using codes in the DS field, etc.

[0150] The forwarding module 1146 may forward the data packet to a suitable output interface of the router according to the destination address of the data packet (eg, according to a routing table).

[0151] The egress shaping module 1148 receives packets from the forwarding module 1146 and performs egress traffic shaping. The egress shaping module 1148 may be part of the egress module 1063 or may correspond to the egress module 1063 configured according to the configuration information stored in the database 1066. The classifier 1150 checks the DSCP value of the received packets and sends the packets to the egress traffic shaper 1151 (egress shaper) and queues 1153 to 1157 according to the category indicated by the DSCP bits in the header of each packet. For example, packets whose DSCP bits in the packet header are set to a value indicating the LGS category are sent to the egress shaper 1151, packets whose DSCP bits in the packet header are set to a value indicating the AF41 category are sent to the AF4x queue 1153, packets whose DSCP bits in the packet header are set to a value indicating the AF31 category are sent to the AF3x queue 1154, packets whose DSCP bits in the packet header are set to a value indicating the AF21 category are sent to the AF2x queue 1155, packets whose DSCP bits in the packet header are set to a value indicating the AF11 category are sent to the AF1x queue 1156, and packets whose DSCP bits in the packet header are set to a value indicating the BE category are sent to the BE queue 1157. The egress shaper 1151 may perform traffic shaping according to a traffic shaping rule (e.g., according to an srTCM scheme, a trTCM scheme, or a leaky bucket scheme). The egress shaper 1151 may measure the LGS category rate and mark the packets with different colors according to the rule obtained from a database (e.g., the egress shaper DB 1074). For example, the egress shaper 1151 may send some packets (green packets) to the LGS queue 1152. The egress shaper 1151 may send some packets (yellow packets) to one of the lower priority queues (e.g., AF4x queue 1153). This is configurable, and in some cases, the yellow packets may be sent to a different queue and may be dropped. The egress shaper 1151 may send some packets (red packets) to one of the lower priority queues (e.g., AF3x queue 1154). This is configurable, and in some cases, the red packets may be sent to a different queue and may be dropped.

[0152] The packets in the LGS queue 1152 are sent directly to the priority scheduler 1160 so that the packets from the EF queue 1152 (green packets) are prioritized to achieve low latency. The packets are sent from the priority scheduler 1160 to one of the ports 1080. The packets from the queues 1153 to 1157 are selected by a suitable weighted fair queuing scheme (e.g., a weighted round robin scheme in the illustrated example). The weighted round robin (WRR) scheduler 1162 manages the queues 1153 to 1157 by selecting packets from the queues 1153 to 1157 using a WRR scheme (e.g., according to a suitable WRR scheduling scheme) and sends the packets to the priority scheduler 1160. The priority scheduler 1160 schedules the packets according to priority (e.g., the LGS packets sent first).

[0153] Although Fig. 9B The example in shows traffic shaping on both the ingress and egress sides, but in other examples, traffic shaping may occur on only one side. For example, ingress traffic shaping may occur on the ingress router side, while subsequent routers on the data path may only perform egress traffic shaping.

[0154] Although Fig. 9B The examples in relate to using a new LGS class or using the EF class for LGS, but other implementations are also possible according to current technology. For example, the AF41 class can be used for LGS with a higher priority EF class packet.

[0155] Fig.10 The network device 1040 is shown to be used to use the newly defined class or AF41 class for LGS (instead of Fig. 9B An example of using EF categories as in the example in . Fig.10 The example in is similar to Fig. 9B . The difference is that here, instead of applying ingress shaper 1142 to LGS packets from LGS marker 1134, the LGS packets can be mapped to the AF41 class so that ingress shaper 1142 is applied to LGS packets from LGS marker 1135 (e.g., based on the class rate and rules in ingress shaper DB 1073). Some LGS packets (green packets) can be sent directly to joiner 1144. Some packets (yellow packets and red packets) can be sent to a lower level marker (e.g., AF31 marker 1136) to be re-marked and then sent to joiner 1144. In this example, the EF packets bypass ingress shaper 1142.

[0156] In the egress shaper module 1148, the EF packets bypass the egress shaper 1151 and reach the first priority scheduler 1160 through the EF queue 1152, while the LGS packets reach the egress shaper 1151. The egress shaper 1151 sends these LGS packets to different queues accordingly (e.g., according to the class rate and the rules in the egress shaper DB 1074). Some LGS packets (green packets) are sent to the LGS queue 1153, while other packets (yellow packets and red packets) are sent to lower-level queues (e.g., AF3x queue 1154 or AF2x queue 1155). Packets from the LGS queue 1153 are sent to the second priority scheduler 1161. Packets from queue 1153 to queue 1157 are managed by WRR scheduler 1162 (e.g., according to an appropriate WRR algorithm) and sent to a second priority scheduler 1161 (which schedules packets according to priority (e.g., LGS packets sent first)) and then to priority scheduler 1160 (which schedules packets according to priority (e.g., EF packets sent first)).

[0157] Although Fig. 9B and Fig.10 The example shown in FIG. 10 involves network device 1040 acting as an ingress router of network 100 and performing classification functions, but other components of network 100 may use the above classifications (DSCP values) to determine the appropriate treatment of different packets (e.g., to prioritize certain packets). For example, router 130, router 140 (and any other routers), and device 120 may communicate with each other through in-band signaling (e.g., Figures 2 to 7 Different classes of packets may be processed differently to meet different class-based QoS requirements (as shown in one or more of the above) by configuring the routers and / or other components. This may be achieved by appropriate traffic shapers (ingress shapers and / or egress shapers) in the routers and / or other components. These traffic shapers (configured based on requirements received via in-band signaling and stored in one or more databases) may use a TCM scheme or other traffic shaping algorithm to appropriately prioritize packets at each component on the data path through the network.

[0158] Fig.11An example of a method of operating a network device is shown. The method includes: receiving a first data packet through a network interface of the network device 1200; obtaining traffic shaping parameters of a traffic shaping scheme for multiple categories of data packets from in-band communications received in the first data packet 1202; and storing the traffic shaping parameters in a database in the network device 1204. The method also includes: receiving a plurality of data packets through the network interface of the network device 1206; identifying corresponding categories of the plurality of data packets 1208; and shaping traffic in the network device using one or more traffic shapers according to the identified categories 1210, wherein the one or more traffic shapers are based on the traffic shaping parameters in the database.

[0159] The technology described herein can be implemented using hardware, software, or a combination of hardware and software. The software used is stored in the above-mentioned one or more processor-readable storage devices to configure one or more processors to perform the functions described herein. The processor-readable storage device may include computer-readable media, such as volatile and non-volatile media, removable and non-removable media. For example, but not limited to, computer-readable media may include computer-readable storage media and communication media. Computer-readable storage media can be implemented using any method or technology to store information such as computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (digital versatile disk, DVD) or other optical disk storage, magnetic cassette, magnetic tape, disk storage or other magnetic storage device, or any other medium that can be used to store the required information and can be accessed by a computer. One or more computer-readable media do not include propagation signals, modulated signals, or transient signals.

[0160] Communication media typically embodies computer readable instructions, data structures, program modules or other data in a propagating data signal, a modulated data signal or a transient data signal (e.g., a carrier wave or other transport mechanism), and includes any information transmission medium. The term "modulated data signal" refers to a signal whose one or more characteristics are set or changed to encode information into the signal. For example, but not limited to, communication media include wired media such as a wired network or a direct wired connection, and wireless media such as RF and other wireless media. Combinations of the above are also included within the scope of computer readable media.

[0161] In alternative embodiments, some or all of the software may be replaced by dedicated hardware logic components. For example, but not limited to, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), special computers, etc. In one embodiment, software (stored in a storage device) that implements one or more embodiments is used to configure one or more processors. The one or more processors may communicate with one or more computer-readable media / storage devices, peripheral devices, and / or communication interfaces.

[0162] It should be understood that the subject matter of the present invention can be embodied in many different ways and should not be construed as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided to make this subject matter thorough and complete, and to fully convey the present invention to those skilled in the art. In fact, the purpose of this subject matter is to cover the substitutes, modifications and equivalents of these embodiments, which are included in the scope and spirit of this subject matter as defined by the appended claims. Moreover, in the detailed description of the subject matter of the present invention, many specific details are set forth to provide a thorough understanding of the subject matter of the present invention. However, it is clear to those of ordinary skill in the art that the subject matter of the present invention can be practiced without these specific details.

[0163] Various aspects of the present invention are described herein in conjunction with the flowchart and / or block diagram of the method, device (system) and computer program product provided in the embodiment of the present invention. It should be understood that each square frame of the flowchart and / or block diagram and the combination of square frames in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable instruction execution device produce a mechanism for implementing the function / action described in detail in the flowchart and / or block diagram.

[0164] The description of the present invention is presented for the purpose of illustration and description, but the description of the present invention is not exhaustive or limited to the present invention in the disclosed form. Various modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the present invention. Various aspects of the present invention are selected and described in order to better explain the principles and practical applications of the present invention, and to enable those of ordinary skill in the art to understand the present invention and various modifications suitable for the intended specific use.

[0165] For the purposes of this document, each process associated with the disclosed technology can be performed serially by one or more computing devices. Each step in the process can be performed by the same or different computing devices used in other steps, and each step does not have to be performed by a single computing device.

[0166] Although the present invention has been described with reference to the specific features and embodiments of the present invention, it is apparent that various modifications and combinations may be made to the present invention without departing from the present invention. Therefore, the specification and the drawings are only regarded as an explanation of the present invention as defined by the appended claims, and it is contemplated that the specification and the drawings cover any and all modifications, variations, combinations or equivalents falling within the scope of the present invention. Although the subject matter has been described in a language specific to structural features and / or method actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are disclosed as exemplary ways of implementing the claims.

Claims

1. A device for operating a network device, characterized in that: The device comprises: A network interface, used to connect to a network; a database for storing traffic shaping parameters of traffic shaping schemes for multiple categories of data packets received by the network interface; a database loading circuit, configured to obtain the traffic shaping parameters from in-band communication received by the network interface in a data packet, and load the traffic shaping parameters into the database, wherein the in-band communication is in a hop-by-hop extension header of an IPv6 data packet, wherein the hop-by-hop extension header carries a class-based quality of service (QoS) requirement, wherein the class-based QoS requirement includes the traffic shaping parameters; wherein the hop-by-hop extension header also carries a first establishment status field, wherein the first establishment status field is used to indicate whether the traffic shaper meets or does not meet the class-based QoS requirement; One or more traffic shapers are used to access the traffic shaping parameters in the database and apply the traffic shaping scheme to the multiple categories of data packets received by the network interface according to the traffic shaping parameters.

2. The device according to claim 1, characterized in that The one or more traffic shapers include an egress shaper configured to send packets of one class to a plurality of queues associated with the plurality of classes of packets.

3. The device according to claim 2, characterized in that The plurality of queues include two or more queues managed by a weighted fair queuing scheduler and at least one priority queue managed by a priority scheduler.

4. The device according to any one of claims 1 to 3, characterized in that The one or more traffic shapers include an ingress shaper configured to instruct packets marked as a first category to be re-marked as one or more other categories.

5. The device according to any one of claims 1 to 3, characterized in that The traffic shaping scheme is a single rate three color marker (srTCM) scheme for the multiple categories of data packets.

6. The device according to any one of claims 1 to 3, characterized in that The traffic shaping scheme is a two rate three color marker (trTCM) scheme.

7. The device according to any one of claims 1 to 3, characterized in that The traffic shaping scheme is a leaky bucket scheme.

8. The device according to claim 5, characterized in that The traffic shaping parameters include a committed information rate (CIR), a committed burst size (CBS) and an exceeded burst size (EBS).

9. The device according to any one of claims 1 to 3, characterized in that The traffic shaper is used to re-mark the data packets belonging to the first category as belonging to the second category, or to place the data packets belonging to the first category in a queue of at least the second category.

10. The device according to any one of claims 1 to 3, characterized in that The multiple categories include at least one of a Latency Guaranteed Service (LGS) category and a Bandwidth Guaranteed Service (BGS) category, the LGS category has an LGS Digital Services Code Point (DSCP), and the BGS category has a BGS DSCP.

11. The device according to claim 10, characterized in that Packets of the LGS category are placed in the highest priority queue or the second highest priority queue.

12. The device according to claim 11, characterized in that Packets of the BGS class are placed in one or more queues with a lower priority than any queues including packets of the LGS class.

13. The device according to claim 12, characterized in that The plurality of categories of data packets include other categories, and the data packets of the other categories are placed in one or more queues with lower priorities.

14. A method for operating a network device, characterized in that: The method comprises: Receiving a first data packet through a network interface of the network device; Obtaining traffic shaping parameters of a traffic shaping scheme for multiple categories of data packets from in-band communications received in the first data packet, the in-band communications being in a hop-by-hop extension header of an IPv6 data packet, the hop-by-hop extension header carrying a category-based quality of service (QoS) requirement, the category-based QoS requirement including the traffic shaping parameters; the hop-by-hop extension header also carrying a first establishment status field, the first establishment status field being used to indicate whether the network device meets or does not meet the category-based QoS requirement; storing the traffic shaping parameters in a database in the network device; receiving a plurality of data packets through the network interface of the network device; identifying corresponding categories of the plurality of packets; Based on the identified categories, traffic in the network device is shaped using one or more traffic shapers configured based on the traffic shaping parameters stored in the database.

15. The method according to claim 14, characterized in that Shaping the traffic in the network device includes sending one category of packets to a plurality of queues associated with the plurality of categories of packets.

16. The method according to claim 15, characterized in that The method further includes selecting a data packet from the plurality of queues managed by a weighted fair queue scheduling scheme and a strict priority scheduling scheme.

17. The method according to any one of claims 14 to 16, characterized in that Shaping the traffic in the network device includes re-marking data packets marked as belonging to a first category as belonging to at least a second category.

18. The method according to any one of claims 14 to 16, characterized in that Shaping traffic in the network device using one or more traffic shapers based on the identified classes includes applying a single rate three color marker (srTCM) scheme for packets of the plurality of classes.

19. The method according to any one of claims 14 to 16, characterized in that Shaping traffic in the network device using one or more traffic shapers based on the identified classes includes applying a two rate three color marker (trTCM) scheme for packets of the plurality of classes.

20. The method according to any one of claims 14 to 16, characterized in that Shaping traffic in the network device using one or more traffic shapers based on the identified classes includes applying a leaky bucket approach to packets of the plurality of classes.

21. The method according to claim 18, characterized in that The obtaining of the traffic shaping parameters of the traffic shaping scheme includes obtaining a service type and associated service parameters from the in-band communication, wherein the service type includes at least one of a committed information rate (CIR), a committed burst size (CBS), and an exceeded burst size (EBS).

22. The method according to claim 21, characterized in that The method further comprises: after acquiring the service type and associated parameters from the in-band communication, checking whether the service type and associated parameters can be provided by the network device.

23. The method according to claim 22, characterized in that The network device is one of a plurality of network devices on a data path, and the method comprises: at each network device side on the data path, checking whether a specified service type with associated parameters can be provided.

24. The method according to claim 14, characterized in that The multiple categories include at least one of a Latency Guaranteed Service (LGS) category and a Bandwidth Guaranteed Service (BGS) category, the LGS category has an LGS Digital Services Code Point (DSCP), and the BGS category has a BGS DSCP; shaping the traffic in the network device according to the identified category includes placing data packets of the LGS category in a highest priority queue or a second highest priority queue.

25. The method according to claim 24, characterized in that The method also includes placing packets of the BGS category in one or more queues having a lower priority than any queues including packets of the LGS category.

26. The method according to claim 25, characterized in that The method also includes placing other categories of data packets in one or more queues with lower priority.

27. The method according to any one of claims 14 to 16, characterized in that The obtaining of the traffic shaping parameters includes reading a hop-by-hop extension header of an IPv6 data packet.

28. A system for operating a network device, characterized in that: The system comprises: A plurality of network devices coupled to a network, wherein each of the plurality of network devices comprises: A network interface for connecting to the network; a database for storing traffic shaping parameters of traffic shaping schemes for multiple categories of data packets received by the network interface; a database loading circuit, configured to obtain the traffic shaping parameters from in-band communication received by the network interface in a data packet, the in-band communication being in a hop-by-hop extension header of an IPv6 data packet, the hop-by-hop extension header carrying a class-based quality of service (QoS) requirement, the class-based QoS requirement including the traffic shaping parameters; the hop-by-hop extension header also carrying a first establishment status field, the first establishment status field being used to indicate whether the traffic shaper meets or does not meet the class-based QoS requirement; One or more traffic shapers are used to access the traffic shaping parameters in the database and apply the traffic shaping scheme to the multiple categories of data packets received by the network interface according to the traffic shaping parameters.

29. The system according to claim 28, characterized in that The one or more traffic shapers include an egress shaper configured to send packets of one class to a plurality of queues associated with the plurality of classes of packets.

30. The system according to claim 29, characterized in that The plurality of queues include two or more queues managed by a weighted fair queuing scheduler and a priority queue managed by a priority scheduler.

31. A system according to any one of claims 28 to 30, characterized in that The one or more traffic shapers include an ingress shaper configured to instruct packets marked as a first category to be re-marked as one or more other categories.

32. A system according to any one of claims 28 to 30, characterized in that The traffic shaping scheme is a single rate three color marker (srTCM) scheme for the multiple categories of data packets.

33. A system according to any one of claims 28 to 30, characterized in that The traffic shaping scheme is a two rate three color marker (trTCM) scheme.

34. A system according to any one of claims 28 to 30, characterized in that The traffic shaping scheme is a leaky bucket scheme.

35. The system according to claim 32, characterized in that The traffic shaping parameters include a committed information rate (CIR), a committed burst size (CBS) and an exceeded burst size (EBS).

36. A system according to any one of claims 28 to 30, characterized in that The traffic shaper is used to re-mark the data packets belonging to the first category as belonging to the second category, or to place the data packets belonging to the first category in a queue of at least the second category.

37. A system according to any one of claims 28 to 30, characterized in that The multiple categories include at least one of a Latency Guaranteed Service (LGS) category and a Bandwidth Guaranteed Service (BGS) category, the LGS category has an LGS Digital Services Code Point (DSCP), and the BGS category has a BGS DSCP.

38. The system according to claim 37, characterized in that Packets of the LGS category are placed in the highest priority queue or the second highest priority queue.

39. The system according to claim 38, characterized in that Packets of the BGS class are placed in one or more queues with a lower priority than any queues including packets of the LGS class.

40. The system according to claim 39, characterized in that The plurality of categories of data packets include other categories, and the data packets of the other categories are placed in one or more queues with lower priorities.

41. A method for operating a network device, characterized in that: The method comprises: Obtaining traffic shaping parameters for multiple categories of data packets according to in-band signaling received on the network device side, the in-band communication being located in a hop-by-hop extension header of an IPv6 data packet, the hop-by-hop extension header carrying a class-based quality of service (QoS) requirement, the class-based QoS requirement including the traffic shaping parameters; the hop-by-hop extension header also carrying a first establishment status field, the first establishment status field being used to indicate whether the network device meets or does not meet the class-based QoS requirement; receiving a plurality of data packets at the network device side; identifying a corresponding category of each of the plurality of categories of packets; The plurality of data packets are shaped according to the traffic shaping parameters of the plurality of categories of data packets, so that at least the data packets of a first category are distributed between the queues of the first category and the queues of a second category.

42. A method for operating a network device, characterized in that: The method comprises: Receiving a first IPv6 data packet through a network interface of the network device; Obtaining traffic shaping parameters of a traffic shaping scheme for multiple categories of data packets from a hop-by-hop extension header of the first IPv6 data packet, wherein the hop-by-hop extension header carries a category-based quality of service (QoS) requirement, and the category-based QoS requirement includes the traffic shaping parameters; the hop-by-hop extension header also carries a first establishment status field, and the first establishment status field is used to indicate whether the network device meets or does not meet the category-based QoS requirement; storing the traffic shaping parameters in a database in the network device; Receiving a plurality of IPv6 data packets through the network interface of the network device; Identifying corresponding categories of the multiple IPv6 data packets according to Differentiated Services Code Point (DSCP) fields in headers of the multiple IPv6 data packets; Based on the identified categories, traffic in the network device is shaped using one or more traffic shapers configured based on the traffic shaping parameters stored in the database.

Images