Patent Description:
Currently, to provide different services for a traffic flow, different flow identifiers need to be encapsulated into packets of the traffic flow based on formats corresponding to the different services. In this way, in a packet forwarding process, a network device may perform operations corresponding to the services on the packets based on the flow identifiers in different formats. However, when a packet of the traffic flow passes through different domains, if network devices in different domains need to provide different services for the packet of the specific traffic flow, format conversion or re-encapsulation needs to be performed on the encapsulated flow identifiers when the packet of the traffic flow is transmitted between different domains. Therefore, processing of the traffic flow passing through different types of domains is complex.

<CIT> relates to message forwarding method and network device. <CIT> relates to a message processing method and a network device.

Implementations of this application provide a method and an apparatus for providing a service for a traffic flow, to improve processing performance of the traffic flow.

According to the method, if a network device serving as a head node or an ingress node determines that a packet feature of the received first packet matches a packet feature of the traffic flow, the network device adds an indication identifier of the traffic flow to the first packet to obtain a second packet, and sends the second packet to an intermediate node. The indication identifier of the traffic flow is used to indicate the service provided for the traffic flow. The intermediate node obtains the indication identifier of the traffic flow from the received second packet, and processes the second packet according to the indication identifier and a processing policy. In this way, the intermediate node may directly identify the indication identifier and perform an operation of a corresponding service, to provide the corresponding service for the traffic flow, without performing format conversion on an encapsulated indication identifier, or performing redundant encapsulation of indication identifiers in a plurality of formats.

In some implementations of the foregoing solutions, the packet including the indication identifier is an Internet Protocol version <NUM> (English: Internet Protocol Version <NUM>, IPv6 for short) or multi-protocol label switching (English: Multi-Protocol Label Switching, MPLS for short) packet.

In the present disclosure, in some implementations, the indication identifier includes an identifier of a service. The service includes one or more of the following services: operations, administration and maintenance (English: Operations, Administration and Maintenance, OAM for short), service function chaining (English: Service Function Chaining, SFC for short), and deterministic networking (English: Deterministic Networking, DetNet for short). When these services are performed, for example, when the packet is an IPv6 packet, an indication identifier included in the IPv6 packet indicates that an OAM operation needs to be performed on the IPv6 packet, and an intermediate node performs the specific OAM operation on the packet according to the indication identifier and a processing policy. For example, one or more operations such as packet loss count, jitter measurement, and delay measurement are performed.

In the present disclosure, in some implementations, the indication identifier further includes an identifier of an operation corresponding to the service and/or a sequence number (Sequence Number) carried in a first packet.

In the present disclosure, in some implementations, when the second packet is the IPv6 packet, the second packet includes an IPv6 extension header, and the IPv6 extension header includes the indication identifier. In this way, the indication identifier may be encapsulated into the IPv6 extension header in the second packet, and the intermediate node parses the received second packet, obtains the indication identifier from the IPv6 extension header, and performs a corresponding service operation on the second IPv6 packet according to the indication identifier and the processing policy. This can effectively improve efficiency of the intermediate node in processing IPv6 packets.

In the present disclosure, in some implementations, in an IPv6 network, the IPv6 extension header includes a hop-by-hop options (Hop-by-Hop Options) header field or a destination options header (Destination Options header) field of the second IPv6 packet. The hop-by-hop options header field or the destination options header field includes the indication identifier.

In the present disclosure, in some implementations, in the SRv6 network, the first IPv6 packet and the second IPv6 packet are segment routing over IPv6 SRv6 packets, the network device supports SRv6, the IPv6 extension header includes a segment routing header SRH of the second IPv6 packet, and the SRH includes the indication identifier. In one case, the SRH includes a segment identifier SID, and the SID includes the indication identifier. In another case, the SID includes an arguments (arguments) field, and the arguments field includes the indication identifier. In still another case, the SRH includes a tag field and/or a flags field, and the tag field or the flags field or both include the indication identifier.

In the present disclosure, in some implementations, still in the SRv6 network, the first IPv6 packet and the second IPv6 packet are SRv6 packets, the network device supports SRv6, the second IPv6 packet includes an IPv6 header, the IPv6 header in the second IPv6 packet includes a source address SA field, and the SA field includes the indication identifier. Alternatively, the first IPv6 packet and the second IPv6 packet are SRv6 packets, the network device supports best effort BE in the SRv6, the IPv6 extension header of the second IPv6 packet includes a destination address DA field in the IPv6 header, and the DA field includes the indication identifier.

In the present disclosure, in some implementations, the second IPv6 packet includes the IPv6 header, the IPv6 header includes a flow label (Flow Label) field, and the flow label field includes the indication identifier.

In the present disclosure, in some implementations, the indication identifier further includes a flow label or a flow identifier.

Currently, services increase continuously, and different flow identifiers need to be encapsulated into packets of a traffic flow based on formats corresponding to different services. In this way, in a packet forwarding process, a network device may perform operations corresponding to services on the packet based on the flow identifiers in different formats.

However, when the packet of the traffic flow passes through different domains, if network devices in different domains provide different services for the packet of the traffic flow, format conversion needs to be performed on an encapsulated flow identifier after the packet of the traffic flow passes through a different domain. Consequently, processing of the packet of the traffic flow passing through different domains is relatively complex. In addition, when a plurality of services are provided for the packet of the traffic flow at the same time, flow identifiers of formats corresponding to the services may be encapsulated into the packet of the traffic flow, that is, the packet includes a plurality of flow identifiers in different formats at the same time. As a result, the packet of the traffic flow carries redundant flow identifiers.

Based on this, in the implementations of this application, when a first packet needs to be transmitted between network devices in an IPv6 network to provide a service, a head node in the network may specifically receive the first packet, and determine whether a packet feature of the first packet matches a packet feature of the traffic flow. If the packet feature of the first packet matches the packet feature of the traffic flow, the head node encapsulates an indication identifier corresponding to the traffic flow into the first packet to obtain a second packet, where the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow. Then, the head node sends the second packet to a next hop of the head node, that is, an intermediate node, so that the intermediate node performs, based on a mapping relationship between an indication identifier in the second packet and the service, an operation corresponding to a corresponding service on the second packet, and so on, until the second packet is sent to a tail node. In some implementations, the second packet may be an IPv6 packet or an MPLS packet, and the first packet may be a packet of any type. In some implementations, the service provided for the traffic flow includes one or more of OAM, SFC, and DetNet. In some implementations, the second packet is the IPv6 packet, and the indication identifier may be carried in an IPv6 extension header in the second packet, a source address SA field in an IPv6 header in the second packet, or a destination address DA field in an IPv6 header in the second packet.

In this way, in the implementations of this application, the head node in the network encapsulates the indication identifier of the traffic flow into the first packet, without encapsulating a flow identifier of a corresponding format for each service. Format conversion does not need to be performed on the encapsulated flow identifier even for cross-domain transmission of the first packet. A network device in each domain may identify the indication identifier and perform a corresponding service operation, to conveniently provide a corresponding service.

For example, a scenario in the implementations of this application may be applied to a network system shown in <FIG> is a schematic diagram of a structure of a network supporting an IPv6. The network includes a head node <NUM>, an intermediate node <NUM>, an intermediate node <NUM>, and a tail node <NUM>. It should be noted that, the head node <NUM>, the intermediate node <NUM>, the intermediate node <NUM>, and the tail node <NUM> may be specifically network devices that support the IPv6 network, for example, may be network devices that support segment routing over IPv6 (English: segment routing over IPv6, SRv6 for short). It may be understood that the head node <NUM>, the intermediate node <NUM>, the intermediate node <NUM>, and the tail node <NUM> may be specifically network devices such as a router or a switch that can forward packets and provide a service in the network.

In this application, a head node may alternatively be an entry node or an ingress node, and the head node is used as an ingress node of a network domain. The head node may be a device with a routing function, for example, a router. The intermediate node may be a device with a routing function, for example, a router.

It may be understood that the foregoing scenario is merely an example in the implementations of this application, and imposes no limitation to the implementations of this application.

With reference to the accompanying drawings, the following describes in detail, by using implementations, a specific implementation of a method for providing a service in the implementations of this application.

<FIG> is a schematic flowchart of a method for providing a service for a traffic flow according to an implementation of this application. It should be noted that the implementation shown in <FIG> may be applied to the network architecture shown in <FIG>, and the nodes shown in <FIG> correspondingly perform steps in the method shown in <FIG>. During specific implementation, the method may include, for example, the following steps.

Step <NUM>: A head node encapsulates an indication identifier into a packet of a traffic flow according to an identifier encapsulation policy.

To enable nodes that the traffic flow passes through to provide different services, different nodes in a network need to perform processing operations corresponding to the nodes on the packet of the traffic flow. In view of this, different policies need to exist in advance for different nodes that the traffic flow passes through. These policies may be an identifier encapsulation policy and a service policy that are directly configured on each node, or may be an identifier encapsulation policy and a service policy that are generated on a controller and separately delivered to a corresponding node. During specific implementation, when the packet of the traffic flow passes through a node in the network, to enable each node that the traffic flow passes through to provide a corresponding service, the head node may encapsulate the indication identifier in the packet of the traffic flow according to the identifier encapsulation policy that is corresponding to the traffic flow and that is configured on the node or delivered by the controller, so that an intermediate node performs, according to the indication identifier and the service policy, an operation of a corresponding service.

To make the description of this implementation clearer, before the specific implementation of step <NUM> is described, the identifier encapsulation policy and the service policy are first described.

The identifier encapsulation policy is used to indicate a correspondence between a packet feature and an indication identifier. The identifier encapsulation policy includes a mapping relationship between a packet feature of the traffic flow and the indication identifier of the traffic flow. The packet feature is used to identify a packet belonging to a traffic flow. The head node may identify, based on the packet feature, whether a currently received packet/packets is/are a packet of a specific traffic flow or packets of specific traffic flows. As an example, the packet feature may include a <NUM>-tuple of the packet (for example, a source IP address, a source port, a destination IP address, a destination port, and a transport layer protocol) or some specific fields in the packet feature.

When the packet received by the head node is an IPv6 packet, the packet feature may include content in a flow label (English: Flow label) field of an IPv6 header in the packet. Alternatively, the packet feature may include a source address and/or a destination address in the packet. Alternatively, the packet feature may include content in a flow identifier (English: Flow ID) field in the IPv6 packet. Alternatively, the packet feature may include two, three, or four of the flow label, the flow ID, the source address, or the destination address in the packet. The indication identifier is used to be encapsulated into a packet matching the packet feature, to indicate the service provided for the traffic flow. In some implementations, for the flow ID field, refer to descriptions in IETF RFC <NUM>. In some implementations, for the flow label field, refer to descriptions in IETF RFC <NUM> or RFC <NUM>.

The service policy is used to represent a correspondence between the indication identifier and the operation corresponding to a service. The service policy includes a mapping relationship between the indication identifier of the traffic flow and the service. The operation corresponding to the service specifically means that the node needs to perform a corresponding processing operation to implement the service for a packet sent in the traffic flow. The service may be a service function chaining (English: Service Function Chaining, SFC for short) service, a deterministic networking (English: Deterministic Networking, DetNet for short) service, a postcard based telemetry (English: Postcard based Telemetry, PBT for short) service, an operations, management and maintenance (English: Operations, Administration and Maintenance, OAM for short), or the like. For the OAM, specific operations may include one or more of specific operations such as packet counting and delay measurement. For the SFC, specific operations may include one or more of network address translation (English: network address translation, NAT for short), firewall filtering, deep packet inspection (English: deep packet inspection, DPI for short), intrusion detection, and the like. For the DetNet service, specific operations may include multi-fed and selective receiving and/or flow identification. For the PBT service, specific operations may include performance data collection and/or flow identification.

According to the claimed invention, the indicator identifier includes an identifier of the service. It may be understood that the indication identifier in the identifier encapsulation policy and the service policy additionally includes any one identifier or a combination of a plurality of identifiers of the following identifiers: an identifier of the traffic flow, and an identifier of an operation corresponding to the service. The identifier of the traffic flow may include a flow ID (English: Flow ID) or a flow label. Packets that carry identifiers of a same traffic flow may be considered as belonging to the same traffic flow.

The identifier of the service specifically includes a flag (English: Flag) or a color (English: Color). In one case, the node that the traffic flow passes through may provide only one service. The indication identifier may carry the Color to indicate whether the service needs to be provided. For example, it is assumed that a node that a traffic flow corresponding to Flow ID = <NUM> passes through provides only an SFC service. If Color = <NUM> is configured in the indication identifier, it is considered that the node that the traffic flow passes through performs an operation corresponding to the SFC service, to ensure that the node that the traffic flow passes through provides the SFC service. If Color = <NUM> is configured, the node that the traffic flow passes through does not perform the operation corresponding to the SFC service, so that the node that the traffic flow passes through does not provide the SFC service. Based on a similar principle, when a value of Color is <NUM>, it may also indicate that the node that the traffic flow passes through performs the operation corresponding to the SFC service, and when the value of Color is <NUM>, it may also indicate that the node that the traffic flow passes through does not perform the operation corresponding to the SFC service. In another case, the node that the traffic flow passes through may provide a plurality of services. In this case, the indication identifier may carry a Flag to indicate a combination of specifically provided services. For example, it is assumed that a node that a traffic flow corresponding to Flow ID = <NUM> passes through may provide the SFC service, the DetNet service, and the PBT service. If Flag = <NUM> is configured in the indication identifier, it is considered that the node that the traffic flow passes through provides the SFC service. If Flag = <NUM> is configured, the node that the traffic flow passes through provides the SFC service and the DetNet service. If Flag = <NUM> is configured, the node that the traffic flow passes through provides the SFC service, the DetNet service, and the PBT service. It should be noted that the Flag or Color may implement indication through bitmask resetting.

In one case, an identifier of the operation corresponding to the service may be specifically a template identifier (English: Template ID), and is used to indicate to perform, on the node processing the traffic flow, a service operation on the traffic flow. For example, if Template ID = <NUM>, it indicates performing an operation of the SFC service on the traffic flow. For another example, if Template ID = <NUM>, it indicates performing operations of the DetNet service and the SFC service on the traffic flow. In another case, the identifier of the operation corresponding to the service may alternatively be operation indication information. For example, the PBT service is requested. If the identifier of the operation corresponding to the service carries one or more of an inbound interface number, an outbound interface number, an inbound timestamp, an outbound timestamp, and other operation indication information, the node that the traffic flow passes through provides the PBT service, and specifically performs a corresponding operation of the service: reporting one or more of the inbound interface number, the outbound interface number, the inbound timestamp, and the outbound timestamp.

It should be noted that the indication identifier may further carry a sequence number (Sequence Number) of the packet. The sequence number is used to identify a sequence number of the packet received by the node, and is generally used to calculate a packet loss status of the traffic flow. For example, for the IPv6 packet, after the head node marks the sequence number in the packet, when the packet is transmitted in the network, the nodes that the packet passes through may determine, based on the sequence number in the packet, whether packet loss occurs.

It may be understood that, for indication identifiers that include different content, the service policy correspondingly has a plurality of possible implementations. As example, the indication identifier may include only the flow ID. In this case, the service policy may be specifically a correspondence between the flow ID and the operation corresponding to the service. For another example, the indication identifier may alternatively include only the template ID. In this case, the service policy may be specifically a correspondence between the template ID and the operation corresponding to the service. For still another example, the indication identifier may alternatively include the flow ID and the flag. In this case, the service policy may be specifically a correspondence between the flow ID, the flag, and the operation corresponding to the service. For yet another example, the indication identifier may alternatively include the flow ID and the template ID. In this case, the service policy may be specifically a correspondence between the flow ID, the template ID, and the operation corresponding to the service. For still yet another example, the indication identifier may alternatively include the flag and the template ID. In this case, the service policy may be specifically a correspondence between the flag, the template ID, and the operation corresponding to the service. For a further example, the indication identifier may alternatively include the flow ID, the flag, and the template ID. In this case, the service policy may be specifically a correspondence between the flow ID, the flag, the template ID, and the operation corresponding to the service. In each example, a sequence number may be added in a scenario in which packet loss statistics need to be collected. In this case, the service policy may further include a correspondence between the sequence number and the operation corresponding to the service. In some implementations, the flow ID in this paragraph may alternatively be replaced with the flow label.

It should be noted that, assuming that a packet is forwarded in a tunnel, each node in the tunnel may use a label stack as a policy for forwarding the packet. For example, the label stack may be an MPLS label stack, or may also be an SRv6 segment list (English: Segment list). The label stack includes the indication identifier. Specifically, the MPLS label stack or the SRv6 segment list includes the indication identifier. More specifically, a last label in the MPLS label stack includes the indication identifier. During specific implementation, the label stack may be configured on the head node of the tunnel, or may be generated by the controller and delivered to the head node of the tunnel, so that the head node of the tunnel encapsulates the label stack into a packet, to indicate transmission of the packet in the tunnel. In this way, when the packet is transmitted on each node of the tunnel, original content of the packet may not be parsed, and an effective transmission path in the tunnel may be learned only by using the label stack. This improves packet forwarding efficiency in the tunnel.

After the identifier encapsulation policy and the service policy are described, the following describes in detail "the head node encapsulates the indication identifier in the packet of the traffic flow according to the identifier encapsulation policy" in step <NUM>.

During specific implementation, when receiving a packet, the head node may first obtain a packet feature of the packet. Then, the packet feature of the packet is matched with the packet feature carried in the identifier encapsulation policy. If the packet feature of the packet matches the packet feature carried in the identifier encapsulation policy, it is considered that the received packet belongs to the traffic flow, and therefore, the indication identifier corresponding to the matched packet feature in the identifier encapsulation policy can be encapsulated into the packet. Otherwise, if the packet feature of the packet does not match the packet feature carried in the identifier encapsulation policy, it is considered that the received packet does not belong to the traffic flow. In this case, no indication identifier is encapsulated into the packet, and subsequent step <NUM> to step <NUM> are not performed. As an example, the matching may specifically mean that the packet feature of the received packet is consistent with a packet feature carried in the identifier encapsulation policy, for example, a <NUM>-tuple in the received packet is consistent with a <NUM>-tuple of a traffic flow.

For example, it is assumed that the identifier encapsulation policy that is received by the head node and delivered by the controller includes: a correspondence between a packet feature A, a flow ID<NUM>, and a template ID<NUM>, a correspondence between a packet feature B, a flow ID<NUM>, and a template ID<NUM>, and a correspondence between a packet feature C, a flow ID<NUM>, and a template ID<NUM>. In one case, when receiving a packet X, the head node obtains a packet feature a of the packet X, and determines that the packet feature a matches the packet feature A in the identifier encapsulation policy, and the head node may encapsulate the indication identifiers: the flow ID<NUM> and the template ID<NUM> that are corresponding to the packet feature A into the packet X. In another case, when receiving a packet Y, the head node obtains a packet feature c of the packet Y, and determines that the packet feature c matches the packet feature C in the identifier encapsulation policy, and the head node may encapsulate the indication identifiers: the flow ID<NUM> and the template ID<NUM> that are corresponding to the packet feature C into the packet Y. In still another case, when receiving a packet Z, the head node obtains a packet feature d of the packet Z, and determines that the packet feature d does not match any of the packet features A, B, and C in the identifier encapsulation policy. In this case, the head node does not encapsulate any indication identifier into the packet Z.

It may be understood that the indication identifier may be encapsulated at any location of the packet theoretically. However, when the encapsulated packet arrives at each intermediate node, each intermediate node needs to read the indication identifier to provide a corresponding service. Some locations in the packet are locations to be read by each intermediate node, and some locations are not read by each intermediate node. If the indication identifier is encapsulated into a location that is not read by each intermediate node, an additional policy needs to be configured or the intermediate node needs to be updated, to ensure that all intermediate nodes can read the indication identifier. This greatly increases costs of providing the service by the node. However, if the indication identifier is encapsulated at the location to be read by each intermediate node, it can be ensured that all the intermediate nodes can read the indication identifier without configuring an additional policy or updating the intermediate node. This effectively reduces costs of providing the service by the node. Based on this, to improve packet processing efficiency of the intermediate node, the indication identifier may be encapsulated into a location that is in the packet and that is to be read by each intermediate node.

In an IPv6 network, after receiving a packet, the head node may encapsulate the received packet into an IPv6 packet, and may encapsulate the indication identifier into an IPv6 extension header. For example, in a schematic diagram of a format of an IPv6 header shown in <FIG>, the indication identifier may be encapsulated into an extension header under the IPv6 header: a hop-by-hop options header (English: Hop-by-Hop Options header) field or a destination options header (English: Destination Options header) field. For another example, in a schematic diagram of another format of the IPv6 header shown in <FIG>, the indication identifier may alternatively be encapsulated into a flow label field in the IPv6 header. It may be understood that, when the IPv6 packet reaches each intermediate node, the hop-by-hop options header, the destination options header in the IPv6 extension header, and the flow label field in the IPv6 header are all read. Therefore, when the indication identifier is encapsulated in the IPv6 header, the intermediate node may obtain the indication identifier without additionally reading another location of the packet or the like. This provides a data basis for the intermediate node to efficiently complete an operation corresponding to a service of the traffic flow.

For example, referring to <FIG>, an example in which the indication identifier is placed in a hop-by-hop options header in an IPv6 extension header is used. The hop-by-hop options header field may include option type, opt data len, and option data fields. The indication identifier may be padded into the option data field. In one case, a format of the indication identifier is as shown in <FIG>, and the indication identifier includes a flow ID and a color. In another case, the format of the indication identifier is as shown in <FIG>, and the indication identifier includes a flow ID and a flag. In still another case, the format of the indication identifier is as shown in <FIG>, and the indication identifier includes a flow ID, a sequence number, a color, and a template ID. In yet another case, the format of the indication identifier is as shown in <FIG>, and the indication identifier includes a flow ID, a sequence number, a flag, and a template ID. In still yet another case, the format of the indication identifier is as shown in <FIG>, and the indication identifier includes a flow ID, a sequence number, and a color. In a further case, the format of the indication identifier is as shown in <FIG>, and the indication identifier includes a flow ID, a sequence number, and a flag.

It should be noted that, to enable the head node to extract related information in the indication identifier from the IPv6 header/extension header, the head node may learn, in a protocol advertisement manner, a format of the indication identifier in the IPv6 header/extension header, and read the corresponding information according to the format, for example, the format shown in <FIG>.

In an SRv6 network, if the head node can encapsulate the received packet into a segment routing over IPv6 (English: segment routing over IPv6, SRv6 for short) packet, in one case, the head node may encapsulate the indication identifier into a segment routing header (English: Segment Routing Header, SRH for short) in the SRv6 packet. For a format of the SRH, refer to <FIG>. For a specific format of the SRH in the SRv6, refer to IPv6 Segment Routing Header (SRH) draft-ietf-6man-segment-routing-header-<NUM> draft.

For example, the indication identifier may be encapsulated into an arguments (Args) field in each segment identifier (English: Segment ID, SID for short) in the SRH. In this way, after the packet is forwarded to each intermediate node, the intermediate nodes can obtain the indication identifier by reading the SID corresponding to the intermediate nodes from the SRH, without additionally reading other information. This improves packet forwarding efficiency.

For another example, the indication identifier may alternatively be encapsulated into optional type length value objects (Option TLV for short) in the SRH or a specified target SID. It should be noted that the target SID may be any original SID in the SRH, or may be a last SID newly added to the SRH. When the indication identifier is encapsulated into the target SID, the controller further needs to deliver a forwarding policy to each intermediate node, to indicate each intermediate node to read the target SID in addition to reading an SID corresponding to the intermediate node, so as to obtain the indication identifier. In this way, redundant encapsulation of the indication identifier at a plurality of locations can be minimized, thereby improving an encapsulation rate of a packet.

For another example, the indication identifier may be encapsulated into a tag field or a flags field in the SRH. Alternatively, parts of the indication identifier may be encapsulated and stored into a tag field and a flags field in the SRH separately. For example, the flow ID and the sequence number are encapsulated into the tag field, and the flag (or Color) and the template ID are encapsulated into the flags field.

In another case in the SRv6 network, referring to a packet format shown in <FIG>, the head node may also encapsulate the indication identifier into an unused source address (English: Source Address, SA for short) in the IPv6 header. When the packet arrives at each intermediate node, the intermediate node reads the indication identifier encapsulated in the SA. Alternatively, in a best effort (English: Best Effort, BE for short) scenario in the SRv6, a destination address (English: Destination Address, DA for short) of an outer IPv6 of the SRv6 is a SID of a tail node. Because a sequence of nodes does not change, the DA of the IPv6 remains unchanged. Therefore, the DA in the IPv6 header may also be used to encapsulate the indication identifier. In this way, when a packet arrives at each intermediate node, the intermediate node reads the indication identifier encapsulated in the DA. In addition, in the SRv6 network, the head node may alternatively add the indication identifier to the SRv6 segment list.

In a multi-protocol label switching (English: Multi-Protocol Label Switching, MPLS for short) network, the head node may encapsulate the received packet into an MPLS packet, and the head node may encapsulate the indication identifier into a label stack in the MPLS packet. For example, refer to a format of an MPLS label shown in <FIG>. The indication identifier may be encapsulated into a last label field in the MPLS label stack, so that when the packet arrives at each intermediate node, the intermediate node reads the indication identifier encapsulated in the last label. The packet forwarded by using the MPLS may be an internet protocol version <NUM> (English: Internet Protocol Version <NUM>, IPv4 for short) packet, or may be an IPv6 packet.

It should be noted that the foregoing describes only several encapsulation locations that can be read by each node as an example.

It should be noted that step <NUM> may be specifically performed by the head node <NUM> in <FIG>, and the head node and a first network device in the following implementations belong to different descriptions of a same device.

It can be learned that the indication identifier is encapsulated into the encapsulation location that can be shared by all nodes in the packet, and the indication identifier uses a format common to a plurality of services, which can overcome current problems such as complex operations and relatively low efficiency when a traffic flow provides different services.

Step <NUM>: The head node sends the packet of the traffic flow to the intermediate node.

It may be understood that the intermediate node in step <NUM> may be a next-hop intermediate node of the head node, for example, the intermediate node <NUM> in <FIG>; and the packet of the traffic flow is a packet encapsulated with the indication identifier.

Step <NUM>: The intermediate node performs, according to the service policy, an operation corresponding to the service on the packet of the traffic flow.

During specific implementation, when the intermediate node receives the packet of the traffic flow into which the indication identifier is encapsulated, the intermediate node may obtain the indication identifier based on the packet of the traffic flow, for example, read, from a specific location in the packet, the indication identifier carried in the packet. Certainly, the indication identifier of the packet may also be calculated in another manner. A service corresponding to the indication identifier is determined according to the service policy and the operation corresponding to the queried service is performed on the packet of the traffic flow.

For example, if the indication identifier includes only the flow ID, and the service policy includes a correspondence between the flow ID and the service, the intermediate node may read the flow ID in the received packet of the traffic flow, and determine a specific service corresponding to the flow ID based on the correspondence between the flow ID and the service. In other words, the intermediate node can perform an operation corresponding to the determined service on the packet of the traffic flow.

For another example, if the indication identifier includes only the template ID, and the service policy includes a correspondence between the template ID and the service, the intermediate node may read the template ID in the received packet of the traffic flow, and determine a specific service corresponding to the template ID based on the correspondence between the template ID and the service. In other words, the intermediate node can perform the operation corresponding to the determined service on the packet of the traffic flow.

For still another example, if the indication identifier includes the flow ID and the flag, and the service policy includes a correspondence between the flow ID, the flag, and the service, the intermediate node may read the flow ID and the flag in the received packet of the traffic flow and determine a specific service corresponding to the flow ID and the flag based on the correspondence between the flow ID, the flag, and the service. In other words, the intermediate node can perform the operation corresponding to the determined service on the packet of the traffic flow.

For yet another example, if the indication identifier includes the flow ID and the template ID, and the service policy includes a correspondence between the flow ID, the template ID, and the service, the intermediate node may read the flow ID and the template ID in the received packet of the traffic flow, and determine a specific service corresponding to the flow ID and the template ID based on the correspondence between the flow ID, the template ID, and the service. In other words, the intermediate node can perform the operation corresponding to the determined service on the packet of the traffic flow.

For still yet another example, if the indication identifier includes the flag and the template ID, and the service policy includes a correspondence between the flag, the template ID, and the service, the intermediate node may read the flag and the template ID in the received packet of the traffic flow, and determine a specific service corresponding to the flag and the template ID based on the correspondence among the flag, the template ID, and the service. In other words, the intermediate node can perform the operation corresponding to the determined service on the packet of the traffic flow.

For a further example, if the indication identifier includes the flow ID, the flag, and the template ID, and the service policy includes a correspondence between the flow ID, the flag, the template ID, and the service, the intermediate node may read the flow ID, the flag, and the template ID in the received packet of the traffic flow, and determine a specific service corresponding to the flow ID, the flag and the template ID based on the correspondence between the flow ID, the flag, the template ID, and the service. In other words, the intermediate node can perform the operation corresponding to the determined service on the packet of the traffic flow.

In some specific service scenarios, the intermediate node may perform operations corresponding to different services on the received packet of the traffic flow, to provide different services.

If the service determined by the intermediate node is a load balancing service implemented by using an equal-cost multi-path routing (English: Equal-cost multi-path routing, ECMP for short) technology, an operation corresponding to the service performed by the intermediate node may be specifically: using the indication identifier as an input of a hash algorithm, and determining a target service path based on an output result of the hash algorithm, to implement load sharing of a plurality of equal-cost paths dedicated to the network.

If the service determined by the intermediate node is the SFC service, the operation corresponding to the service performed by the intermediate node may be specifically: The intermediate node determines a carried service function based on the indication identifier in the packet, and sends the packet of the traffic flow to a service function processing module SF corresponding to the service function for processing. After SF completes processing, the packet of the traffic flow is returned to the intermediate node for a next provided service function. For example, the service function may specifically include deep packet inspection (English: Deep Packet Inspection, DPI for short), a firewall, and the like.

If the service determined by the intermediate node is the DetNet service, the operation corresponding to the service performed by the intermediate node may be specifically: When the head node sends a packet to the intermediate node through a plurality of paths, the intermediate node performs multi-fed and selective receiving on the packet by using the sequence number encapsulated in the packet. In other words for each received packet, the intermediate node determines, based on the sequence number, whether the packet has been received; and if the packet is received, deletes the repeatedly received packet.

If the service determined by the intermediate node is a path segment service, the operation corresponding to the service performed by the intermediate node may be specifically: determining, based on the indication identifier, a service path segment that the traffic flow passes through.

If the service determined by the intermediate node is the PBT service, the operation corresponding to the service performed by the intermediate node may be specifically: identifying the traffic flow based on the indication identifier, and then starting to collect and report related performance information of the traffic flow, for example, the inbound interface number, the outbound interface number, the inbound timestamp, the outbound timestamp, and the packet loss statistics.

It should be noted that, after receiving the packet of the traffic flow, each intermediate node performs step <NUM> to process the received packet of the traffic flow. After completing corresponding processing on the packet of the traffic flow, the intermediate node continues to send the packet of the traffic flow to the next-hop intermediate node. Then, the next-hop intermediate node further performs step <NUM> to process the received packet of the traffic flow. By analogy, all the intermediate nodes perform step <NUM>, and then the following step <NUM> is performed.

For example, assuming that the path sequentially includes a head node <NUM>, a tunnel intermediate node <NUM>, an intermediate node <NUM>, and a tail node <NUM>, the head node <NUM> sends a traffic flow packet R encapsulated with the indication identifier to the intermediate node <NUM>. After the intermediate node <NUM> performs the operation corresponding to the service on the traffic flow packet R according to the service policy, the intermediate node <NUM> sends the traffic flow packet R to the intermediate node <NUM>. The intermediate node <NUM> performs the operation corresponding to the service on the traffic flow packet R according to the service policy. After completing processing, the intermediate node <NUM> identifies that the intermediate node <NUM> is the last intermediate node on the path, and a next hop is the tail node. It is considered that step <NUM> of the service provided by the current traffic flow is completed.

It should be noted that step <NUM> may be specifically performed by the intermediate node <NUM> and the intermediate node <NUM> in <FIG> in sequence.

It should be noted that if the head node also has the service policy, the head node may also perform step <NUM>, that is, perform the operation corresponding to the service on the packet of the traffic flow according to the service policy. For specific implementation, refer to related descriptions of implementation of the intermediate node.

Step <NUM>: The head node sends the packet of the traffic flow to the tail node.

During specific implementation, after all the intermediate nodes perform step <NUM>, the last intermediate node may send the packet of the traffic flow to the tail node. After receiving the packet of the traffic flow, the tail node may decapsulate the packet of the traffic flow, for example, decapsulate the indication identifier encapsulated in the packet of the traffic flow in step <NUM>, to obtain the packet of the traffic flow initially received by the head node. In this way, it may be considered that a process of providing the service for the traffic flow is completed.

For example, after the last intermediate node <NUM> on the path performs a service operation on the traffic flow packet R according to the service policy, the intermediate node <NUM> may send the traffic flow packet R to the tail node <NUM>, and the tail node <NUM> decapsulates the traffic flow packet R, that is, decapsulates the encapsulated indication identifier from the traffic flow packet R, to obtain the packet of the traffic flow initially received by the head node <NUM>, so as to complete the service provided for the traffic flow at the current time.

It should be noted that step <NUM> may be specifically performed by the tail node <NUM> in <FIG>.

It should be noted that if the tail node also has the service policy, the tail node may also perform step <NUM>, that is, perform the operation corresponding to the service on the packet of the traffic flow according to the service policy, and then perform a subsequent operation such as decapsulation on the packet of the traffic flow.

In this way, in the method for providing a service for a traffic flow provided in this implementation of this application, the indication identifier that can be identified by all services is introduced to indicate a service that needs to be provided for the traffic flow. In addition, the indication identifier is encapsulated at the location that can be shared by all the nodes (that is, a field that can be directly read after the packet of the traffic flow is received). This is to ensure that each node can perform an operation of a corresponding service on the packet of the traffic flow to provide a corresponding service after receiving the packet of the traffic flow, without performing additional operations such as reading, query, and parsing, and flow identifier conversion during cross-domain transmission. In this way, a node that the traffic flow passes through can simply and efficiently provide various services.

In addition, an implementation of this application further provides a method for providing a service for a traffic flow. In the method, an indication identifier is encapsulated into an IPv6 header/extension header, and a head node is used as a network device that performs the method. Referring to <FIG>, the method may specifically include the following steps.

Step <NUM>: The network device receives a first packet, and the network device supports an IPv6.

Step <NUM>: If a packet feature of the first packet matches a packet feature of the traffic flow, the network device encapsulates an indication identifier of the traffic flow into the first packet to obtain a second IPv6 packet, where the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow.

Step <NUM>: The network device sends the second IPv6 packet.

The indication identifier includes an identifier of the service.

It may be understood that the service includes any one or more of the following services: operations, administration and maintenance OAM, service function chaining SFC, and deterministic networking DetNet.

As an example, the indication identifier further includes an identifier of an operation corresponding to the service and/or a sequence number (Sequence Number) carried in the first packet.

It may be understood that the second IPv6 packet includes an IPv6 extension header, and the IPv6 extension header includes the indication identifier.

In an IPv6 network, the IPv6 extension header includes a hop-by-hop options (Hop-by-Hop Options) header field or a destination options header (Destination Options header) field in the second IPv6 packet. The hop-by-hop options header field or the destination options header field includes the indication identifier.

In an SRv6 network, the second IPv6 packet is a segment routing over IPv6 SRv6 packet, the network device supports the SRv6, the IPv6 extension header includes a segment routing header SRH of the second IPv6 packet, and the SRH includes the indication identifier. In one case, the SRH includes a segment identifier SID, and the SID includes the indication identifier. In another case, the SID includes an arguments (arguments) field, and the arguments field includes the indication identifier. In still another case, the SRH includes a tag field and/or a flags field, and the tag field or the flags field or both include the indication identifier. The SRv6 packet includes an SRv6 segment list (English: Segment list). The SRv6 segment list includes the indication identifier. More specifically, a last label in an MPLS label stack includes the indication identifier.

In addition, when the second IPv6 packet is the SRv6 packet, the network device supports the SRv6, the second IPv6 packet includes the IPv6 header, the IPv6 header of the second IPv6 packet includes a source address SA field, and the SA field includes the indication identifier. In an implementation, the second IPv6 packet is the SRv6 packet, the network device supports SRv6 best effort BE, the IPv6 extension header in the second IPv6 packet includes a destination address DA field in the IPv6 header, and the DA field includes the indication identifier.

In addition, the second IPv6 packet includes the IPv6 header, the IPv6 header includes a flow label (Flow Label) field, and the flow label field includes the indication identifier.

In another example, the indication identifier further includes a flow label or a flow identifier.

It should be noted that for a specific implementation and an effect of the implementation shown in <FIG>, refer to related descriptions of step <NUM> and step <NUM> in <FIG>.

In addition, an implementation of this application further provides a method for providing a service for a traffic flow. In the method, an indication identifier is encapsulated into an IPv6 header/extension header, and an intermediate node is used as a network device that performs the method. Referring to <FIG>, the method may specifically include the following steps.

Step <NUM>: The network device receives a packet, and the network device supports an IPv6.

Step <NUM>: The network device obtains an indication identifier of a traffic flow from the packet, where the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow.

Step <NUM>: The network device performs an operation corresponding to the service on the packet based on a mapping relationship between the indication identifier and the service.

Step <NUM>: The network device sends the packet including the indication identifier.

As an example, the indication identifier further includes an identifier of the operation corresponding to the service and/or a sequence number (Sequence Number) of the received packet.

It may be understood that the packet including the indication identifier is an IPv6 packet, the IPv6 packet includes an IPv6 extension header, and the IPv6 extension header includes the indication identifier. The IPv6 extension header includes a hop-by-hop options header field or a destination options header field of the IPv6 packet. The hop-by-hop options header field or the destination options header field includes the indication identifier.

In an SRv6 network, the packet including the indication identifier is a segment routing over IPv6 SRv6 packet, the network device supports the SRv6, the IPv6 extension header includes an SRH of the packet, and the SRH includes the indication identifier. In one case, the SRH includes a segment identifier SID, and the SID includes the indication identifier. In another case, the SID includes an arguments (arguments) field, and the arguments field includes the indication identifier. In still another case, the SRH includes a tag field and/or a flags field, and the tag field or the flags field or both include the indication identifier.

In addition, the packet including the indication identifier is the SRv6 packet, the network device supports the SRv6, the SRv6 packet includes the IPv6 header, the IPv6 header includes a source address SA field, and the SA field includes the indication identifier. In some implementations, the network device supports SRv6 BE, the SRv6 packet includes the IPv6 header, the IPv6 header in the SRv6 packet includes a destination address DA field, and the DA field includes the indication identifier.

In addition, the packet including the indication identifier includes the IPv6 header, the IPv6 header includes a flow label (Flow Label) field, and the flow label field includes the indication identifier.

In yet another example, the indication identifier further includes a flow label or a flow identifier.

In addition, an implementation of this application further provides a method for providing a service for a traffic flow. In the method, an indication identifier is encapsulated into an MPLS label stack, and a head node is used as a network device that performs the method. Referring to <FIG>, the method may specifically include the following steps.

Step <NUM>: The network device receives a first packet.

Step <NUM>: If a packet feature of the first packet matches a packet feature of the traffic flow, the network device encapsulates, into the first packet, a multi-protocol label switching MPLS protocol label stack corresponding to the traffic flow, to obtain a second packet, where the label stack includes the indication identifier of the traffic flow, and an indication identifier of the traffic flow is used to indicate the service provided for the traffic flow.

Step <NUM>: The network device sends the second packet.

It may be understood that the service includes any one or more of the following services: operations, administration and maintenance OAM, service function chaining SFC, or deterministic networking DetNet.

It may be understood that a last label in the label stack includes the indication identifier.

In addition, an implementation of this application further provides a method for providing a service for a traffic flow. In the method, an indication identifier is encapsulated into an MPLS label stack, and an intermediate node is used as a network device that performs the method. Referring to <FIG>, the method may specifically include the following steps.

Step <NUM>: The network device receives a packet.

Step <NUM>: The network device reads the indication identifier of the traffic flow from a label stack of the packet, where the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow.

Step <NUM>: The network device performs an operation corresponding to the service based on a mapping relationship between the indication identifier and the service.

Step <NUM>: The network device sends the packet.

The label stack may be the MPLS label stack, or may be an SRv6 segment list (English: Segment list). The label stack includes the indication identifier. Specifically, the MPLS label stack or the SRv6 segment list includes the indication identifier. More specifically, a last label in the MPLS label stack includes the indication identifier.

As an example, the indication identifier further includes the identifier of an operation corresponding to the service and/or a sequence number Sequence Number carried in the packet.

<FIG> is a schematic diagram of a structure of an apparatus <NUM> for providing a service for a traffic flow according to an implementation of this application. The apparatus <NUM> includes a receiving unit <NUM>, an encapsulation unit <NUM>, and a sending unit <NUM>. The receiving unit <NUM> is configured to receive a first packet. The encapsulation unit <NUM> is configured to: if a packet feature of the first packet matches a packet feature of the traffic flow, encapsulate an indication identifier of the traffic flow into the first packet to obtain a second packet, where the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow. The sending unit <NUM> is configured to send the second packet.

In some implementations, the second packet is an IPv6 packet or an MPLS packet.

The indication identifier includes an identifier of the service. The service includes any one or more of the following services: operations, administration and maintenance OAM, service function chaining SFC, or deterministic networking DetNet.

As an example, the indication identifier further includes an identifier of an operation corresponding to the service and/or a sequence number (Sequence Number) carried in the first IPv6 packet.

In some implementations, when the second packet is the IPv6 packet, the second packet includes an IPv6 extension header, and the IPv6 extension header includes the indication identifier. In this way, the indication identifier may be encapsulated into the IPv6 extension header that is in the packet and that is to be read by each intermediate node, to improve packet processing efficiency of the intermediate node.

In other implementations, in the IPv6 network, the IPv6 extension header in the second packet includes a hop-by-hop options (Hop-by-Hop Options) header field or a destination options header (Destination Options header) field in the second packet. The hop-by-hop options header field or the destination options header field includes the indication identifier.

In still other implementations, in an SRv6 network, the second packet is a segment routing over IPv6 SRv6 packet, the apparatus <NUM> support the SRv6, where the SRv6 packet includes the IPv6 extension header, the IPv6 extension header includes a segment routing header SRH of the second packet, and the SRH includes the indication identifier. In one case, the SRH includes a segment identifier SID, and the SID includes the indication identifier. In another case, the SID includes an arguments (arguments) field, and the arguments field includes the indication identifier. In still another case, the SRH includes a tag field and/or a flags field, and the tag field or the flags field or both include the indication identifier.

In other implementations, still in the SRv6 network, the second packet is the SRv6 packet, the apparatus <NUM> supports the SRv6, the second packet includes an IPv6 header, the IPv6 header in the second packet includes a source address SA field, and the SA field includes the indication identifier. In some implementations, the second packet is the SRv6 packet, the apparatus <NUM> supports SRv6 best effort BE, the IPv6 extension header in the second IPv6 packet includes a destination address DA field in the IPv6 header, and the DA field includes the indication identifier.

In addition, the second packet includes the IPv6 header, the IPv6 header includes a flow label (Flow Label) field, and the flow label field includes the indication identifier.

It should be noted that the indication identifier further includes a flow label or a flow identifier.

It may be understood that, for various specific implementations of the apparatus <NUM> shown in <FIG>, refer to the description of the implementation shown in <FIG>. Details are not described in this implementation again.

<FIG> is a schematic diagram of a structure of an apparatus <NUM> for providing a service for a traffic flow according to an implementation of this application. The apparatus <NUM> may specifically include a receiving unit <NUM>, an obtaining unit <NUM>, an execution unit <NUM>, and a sending unit <NUM>. The receiving unit <NUM> is configured to receive a packet. The obtaining unit <NUM> is configured to obtain an indication identifier of a traffic flow based on the received packet, where the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow. The execution unit <NUM> is configured to perform an operation corresponding to the service on the packet, based on a mapping relationship between the indication identifier and the service. The sending unit <NUM> is configured to send the packet including the indication identifier.

In an example, the indication identifier further includes an identifier of the operation corresponding to the service and/or a sequence number (Sequence Number) of the received packet.

In some implementations, the packet including the indication identifier is an IPv6 packet, the packet including the indication identifier includes an IPv6 extension header, and the IPv6 extension header includes the indication identifier. In this way, the indication identifier may be encapsulated into the IPv6 extension header that is in the packet and that is to be read by each intermediate node, to improve packet processing efficiency of the intermediate node. In other implementations, the IPv6 extension header includes a hop-by-hop options header field or a destination options header field of the IPv6 packet, where the hop-by-hop options header field or the destination options header field includes the indication identifier.

In still other implementations, in the SRv6 network, the packet including the indication identifier is a segment routing over IPv6 SRv6 packet, the apparatus <NUM> supports SRv6, the IPv6 extension header includes an SRH of the packet, and the SRH includes the indication identifier. In one case, the SRH includes a segment identifier SID, and the SID includes the indication identifier. In another case, the SID includes an arguments (arguments) field, and the arguments field includes the indication identifier. In still another case, the SRH includes a tag field and/or a flags field, and the tag field or the flags field or both include the indication identifier.

In yet other implementations, still in the SRv6 network, the packet including the indication identifier is the SRv6 packet, the apparatus <NUM> supports the SRv6, the SRv6 packet includes an IPv6 header, the IPv6 header includes a source address SA field, and the SA field includes the indication identifier. In some implementations, the packet including the indication identifier is the SRv6 packet, the apparatus <NUM> supports SRv6 BE, the SRv6 packet includes the IPv6 header, the IPv6 header in the SRv6 packet includes a destination address DA field in the IPv6 header, and the DA field includes the indication identifier.

In some implementations, the packet including the indication identifier includes the IPv6 header, the IPv6 header includes a flow label (Flow Label) field, where the flow label field includes the indication identifier.

<FIG> is a schematic diagram of a structure of an apparatus <NUM> for providing a service for a traffic flow according to an implementation of this application. The apparatus <NUM> includes a receiving unit <NUM>, an encapsulation unit <NUM>, and a sending unit <NUM>. The receiving unit <NUM> is configured to receive a first packet. The encapsulation unit <NUM> is configured to: if a packet feature of the first packet matches a packet feature of the traffic flow, encapsulate a multi-protocol label switching MPLS protocol label stack corresponding to the traffic flow into the first packet, to obtain a second packet, where the label stack includes the indication identifier of the traffic flow, and the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow. The sending unit <NUM> is configured to send the second packet.

In an example, the indication identifier further includes an identifier of an operation corresponding to the service and/or a sequence number (Sequence Number) carried in the first packet.

In some implementations, a last label in the label stack includes the indication identifier.

<FIG> is a schematic diagram of a structure of an apparatus <NUM> for providing a service for a traffic flow according to an implementation of this application. The apparatus <NUM> may specifically include a receiving unit <NUM>, an obtaining unit <NUM>, an execution unit <NUM>, and a sending unit <NUM>. The receiving unit <NUM> is configured to receive a packet. The obtaining unit <NUM> is configured to read an indication identifier of the traffic flow from a label stack of the packet, where the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow. The execution unit <NUM> is configured to perform an operation corresponding to the service on the packet, based on a mapping relationship between the indication identifier and the service. The sending unit <NUM> is configured to send the packet. The label stack may be an MPLS label stack, or may be an SRv6 segment list (English: Segment list). The label stack includes the indication identifier. Specifically, the MPLS label stack or the SRv6 segment list includes the indication identifier. More specifically, a last label in the MPLS label stack includes the indication identifier.

In an example, the indication identifier further includes an identifier of the operation corresponding to the service and/or a sequence number (Sequence Number) of the packet.

Any one of the foregoing apparatus <NUM>, apparatus <NUM>, apparatus <NUM>, and apparatus <NUM> may be located on a network device that supports IPv6.

In addition, an implementation of this application further provides a computer program product. When the computer program product runs on a computer, the computer performs the method for providing a service for a traffic flow in any implementation of the methods shown in <FIG>.

In addition, an implementation of this application further provides a computer-readable storage medium. The computer-readable storage medium stores instructions. When the instructions are run on a computer or a processor, the computer or the processor is enabled to perform the method for providing a service for a traffic flow in any possible implementation of the methods shown in <FIG>.

"First" in terms such as the "first IPv6 packet" and the "first packet" mentioned in the implementations of this application is merely used as a name identifier, but does not represent the first position in sequence. This rule is also applicable to "second" and the like.

From the foregoing descriptions of the implementations, a person skilled in the art may clearly understand that some or all steps of the methods in the implementations may be implemented by software in addition to a universal hardware platform. Based on such an understanding, the technical solutions of this application may be implemented in a form of a software product. The software product may be stored in a storage medium, such as a read-only memory (English: read-only memory, ROM)/RAM, a magnetic disk, or an optical disc, and includes several instructions for instructing a computer device (which may be a personal computer, a server, or a network communications device such as a router) to perform the methods described in the implementations or some parts of the implementations of this application.

The implementations in this specification are all described in a progressive manner, for same or similar parts in the implementations, reference may be made to these implementations, and each implementation focuses on a difference from other implementations. Especially, apparatus and device implementations are basically similar to a method implementation, and therefore is described briefly. For related parts, refer to partial descriptions in the method implementation. The described method, apparatus and device implementations are merely examples. The modules described as separate parts may or may not be physically separate, and parts displayed as modules may or may not be physical modules, may be located in one position, or may be distributed on a plurality of network units. Some or all the modules may be selected according to actual needs to achieve the objectives of the solutions of the implementations. A person of ordinary skill in the art may understand and implement the implementations of the present invention without creative efforts.

Claim 1:
A method for providing services for a traffic flow, comprising:
receiving, by a network device, a first packet;
if a packet feature of the first packet matches a packet feature of the traffic flow, encapsulating (<NUM>), by the network device, an indication identifier of the traffic flow into the first packet to obtain a second packet, wherein the indication identifier of the traffic flow is used to indicate the service provided for the traffic flow; and
sending (<NUM>), by the network device, the second packet;
wherein the indication identifier comprises an identifier of the service, wherein the identifier of the service comprises a flag or a color, when a node that the traffic flow passes through provides only one service, the indication identifier carries the color to indicate whether the service needs to be provided and when a node that the traffic flow passes through provides a plurality of services, the indication identifier carries a flag to indicate a combination of one or more services.