WO2021213045A1 - 一种基于随流检测的报文处理方法及装置 - Google Patents

一种基于随流检测的报文处理方法及装置 Download PDF

Info

Publication number
WO2021213045A1
WO2021213045A1 PCT/CN2021/079921 CN2021079921W WO2021213045A1 WO 2021213045 A1 WO2021213045 A1 WO 2021213045A1 CN 2021079921 W CN2021079921 W CN 2021079921W WO 2021213045 A1 WO2021213045 A1 WO 2021213045A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
domain
node
protocol
flow
Prior art date
Application number
PCT/CN2021/079921
Other languages
English (en)
French (fr)
Inventor
储伯森
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP21793650.9A priority Critical patent/EP4131855A4/en
Priority to JP2022564126A priority patent/JP2023522736A/ja
Publication of WO2021213045A1 publication Critical patent/WO2021213045A1/zh
Priority to US17/971,327 priority patent/US20230045227A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/026—Capturing of monitoring data using flow identification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/12—Network monitoring probes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/20—Hop count for routing purposes, e.g. TTL
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/34—Source routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/645—Splitting route computation layer and forwarding layer, e.g. routing according to path computational element [PCE] or based on OpenFlow functionality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L2012/4629—LAN interconnection over a backbone network, e.g. Internet, Frame Relay using multilayer switching, e.g. layer 3 switching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2212/00—Encapsulation of packets

Definitions

  • This application relates to the field of communications, and in particular to a method and device for processing messages based on flow detection.
  • the flow detection technology can be used to detect the performance of the data communication network, for example, to detect the delay and packet loss of the data communication network.
  • the flow detection technology may be, for example, flow information telemetry (in-situ flow information telemetry, iFIT) technology or inband operation management and maintenance (inband operation administration and maintenance, iOAM) technology.
  • the embodiments of the present application provide a packet processing method and device based on flow detection, which can perform performance detection using flow detection technology when multiple bearer protocols are deployed in the detection domain.
  • the embodiments of the present application provide a packet processing method based on flow detection.
  • flow detection technology it is not possible to use flow detection technology to perform performance detection. This is because the packet encapsulation formats corresponding to different bearer protocols are different.
  • the message needs to be re-encapsulated once. Then the flow detection information carried in the message will be stripped. Therefore, the flow detection information cannot be transmitted in the entire detection domain, so that the flow detection technology cannot perform performance detection on the detection domain.
  • the first node in the detection domain after the first node in the detection domain receives the first message from the second node, it can obtain the second message according to the first message.
  • the first packet header of the first packet includes the first flow-following detection information
  • the first packet is a packet encapsulated using the first bearer protocol.
  • the first node can use the second bearer protocol to re-encapsulate the first packet.
  • the first node does not strip the first flow-dependent detection information, but removes the first flow-dependent detection information.
  • the information is added to the message encapsulated by the second bearer protocol, so as to obtain the second message including the first flow-following detection information.
  • the second message may be forwarded to the third node, so that the second message containing the first flow detection information continues to be transmitted in the detection domain.
  • the first bearer protocol is IPv4, IPv6, MPLS, VLAN, GRE, NSH, or Internet Protocol version 6 segment routing SRv6 protocol
  • the second bearer protocol is IPv4, IPv6 Protocol, MPLS protocol, VLAN protocol, GRE protocol, NSH protocol or SRv6 protocol, the first bearer protocol and the second bearer protocol are different.
  • the first flow-following detection information is used to indicate performance parameters of a detection detection domain
  • the detection domain includes a first domain and a second domain
  • the second node belongs to the first domain
  • the third node belongs to the second domain
  • the first node is a cross-domain node of the first domain and the second domain.
  • the first node serves as a cross-domain node between the first domain and the second domain, and can transmit the first packet carrying the first flow detection information across the first domain and the second domain.
  • the first flow-following detection information is not stripped, so that the first flow-following detection information can be transmitted in the entire detection domain.
  • the first node is a service function proxy SF proxy
  • the third node is a service function SF device.
  • the first node may also receive a third message returned by the third node, and the third message includes the The first flow-following detection information, the third message is a message encapsulated using the second bearer protocol; the first node generates a fourth message according to the third message, and the fourth message The message includes the first flow-following detection information, the fourth message is a message encapsulated using the first bearer protocol; the first node sends the first message to a next-hop node.
  • the first packet can pass through the SF device during the transmission process without losing the first flow detection information, so that the first flow detection information can continue to be transmitted to the next hop node.
  • the first domain deploys an SRv6 network
  • the second domain deploys an IPv4 network
  • the first message is an SRv6 message carrying service chain SFC information
  • the second message is carrying The IPv4 message of the SFC information.
  • the flow detection technology can also be used to perform performance detection in the detection domain.
  • the first domain deploys an IPv4 network
  • the second domain deploys an SRv6 network
  • the first message is an IPv4 message carrying SFC information
  • the second message is an IPv4 message carrying SFC information.
  • SRv6 message when the SRv6 network and IPv4 network are deployed in the detection domain, the flow detection technology can also be used to perform performance detection in the detection domain.
  • the first domain deploys an MPLS network
  • the second domain deploys an IPv4 network
  • the first message is an MPLS message
  • the second message is an IPv4 message.
  • the flow detection technology can also be used to perform performance detection in the detection domain.
  • the first domain deploys a three-layer virtual private network L3VPN.
  • the detection domain further includes a third domain, the third domain deploys an MPLS network, and the third node is a cross-domain node of the second domain and the third domain.
  • the flow detection technology can also be used to perform performance detection in the detection domain.
  • the third domain deploys L3VPN.
  • the first domain is a first autonomous system AS
  • the first node is an autonomous system border router ABSR of the first AS
  • the third domain is a second AS
  • the first node is The three nodes are the ABSR of the second AS.
  • the first domain deploys an IPv4 network
  • the second domain deploys an MPLS network
  • the first message is an IPv4 message
  • the second message is an MPLS message.
  • the flow detection technology can also be used to perform performance detection in the detection domain.
  • the second domain deploys L3VPN.
  • the first flow-following detection information includes: iFIT flow-following detection information, or iOAM flow-following detection information.
  • an embodiment of the present application provides a first node, including: a communication interface; and a processor connected to the communication interface; according to the communication interface and the processor, the first node is configured to Perform any of the methods described in the first aspect above.
  • an embodiment of the present application provides a first node, the first node includes a memory and a processor; the memory is used for storing program code; the processor is used for running the program code Instructions to cause the first node to execute the method described in any one of the first aspects above.
  • an embodiment of the present application provides a computer-readable storage medium that stores instructions in the computer-readable storage medium, which when run on a computer, causes the computer to execute any one of the first aspect above The method described.
  • FIG. 1 is a schematic diagram of a network architecture provided by an embodiment of this application.
  • Figure 2 is a schematic diagram of an exemplary application scenario provided by an embodiment of the application.
  • FIG. 3 is a schematic diagram of another exemplary application scenario provided by an embodiment of the application.
  • FIG. 4 is a signaling interaction diagram of a packet processing method based on flow detection according to an embodiment of this application;
  • FIG. 5a is a schematic structural diagram of a possible SRv6 message provided by an embodiment of this application.
  • FIG. 5b is a schematic structural diagram of another possible SRv6 message provided by an embodiment of this application.
  • FIG. 5c is a schematic structural diagram of another possible SRv6 message provided by an embodiment of this application.
  • FIG. 6a is a schematic structural diagram of a possible IPv4 packet provided by an embodiment of this application.
  • FIG. 6b is a schematic diagram of another possible structure of an IPv4 packet provided by an embodiment of this application.
  • FIG. 6c is a schematic diagram of another possible structure of an IPv4 packet provided by an embodiment of this application.
  • FIG. 7 is a signaling interaction diagram of a packet processing method based on flow detection according to an embodiment of this application.
  • FIG. 8a is a schematic structural diagram of a possible MPLS packet provided by an embodiment of this application.
  • FIG. 8b is a schematic diagram of a structure of iFIT flow-on detection information provided by an embodiment of this application.
  • FIG. 8c is a schematic diagram of a structure of iOAM flow detection information provided by an embodiment of this application.
  • FIG. 9 is a schematic flowchart of a packet processing method based on flow detection according to an embodiment of this application.
  • FIG. 10 is a schematic structural diagram of a first node provided by an embodiment of this application.
  • FIG. 11 is a schematic structural diagram of a first node provided by an embodiment of this application.
  • FIG. 12 is a schematic structural diagram of a first node provided by an embodiment of this application.
  • the embodiment of the present application provides a packet processing method based on flow detection, which can also use flow detection technology to perform performance detection when multiple bearer protocols are deployed in the detection domain.
  • the flow-following detection technology can use the flow-following detection information carried in the message to perform characteristic marking on the service flow in the network, and the characteristic marking may also be called dyeing.
  • the nodes passing by the service flow report the collected data such as timestamp and packet number to the control and management device, so that the control and management device can further calculate the network delay and packet loss based on the reported data.
  • the detection domain In a network, you can specify the detection domain to determine the network range that needs to perform the flow detection. Generally, the nodes in the detection domain need to transmit the flow detection information to realize the flow detection, and the information obtained after the flow detection is executed The corresponding information is sent to the control management device.
  • the detection range of the detection domain can be determined based on multiple methods. For example, it can be determined based on network scenarios, such as designating a core network part of the network as the detection domain; or, it can be determined based on service types, such as video services and voice services. The business specifies detection domains of different scopes, etc.
  • the detection domain includes three types of nodes, specifically a head node (English: head node), a tail node (English: end node), and a hop-by-hop path node (English: path node). Among them, the hop-by-hop path node can also be called an intermediate node.
  • the head node, tail node and path node may be corresponding network nodes in the network, for example.
  • the first network node that transmits the service flow within the detection range specified by the detection domain may be used as the head node for transmitting the service flow.
  • the last network node that transmits the service flow within the detection range specified by the detection domain may be used as the tail node for transmitting the service flow.
  • Each node that transmits the service flow between the head node and the tail node is a hop-by-hop path node. Flow detection information can be added by the head node and stripped at the tail node.
  • FIG. 1 is a schematic diagram of a network architecture provided by an embodiment of the application.
  • the network 100 includes a control management device and a plurality of network nodes.
  • the multiple network nodes are connected by a communication link, and are used to transmit service streams.
  • the head node, the intermediate node 1, the intermediate node 2, and the tail node in the detection domain are connected by a communication link.
  • the detection domain may also include other nodes not shown.
  • the tail node can also be connected to an external node through a communication link.
  • the head node can receive the service flow from other devices, and the service flow can reach the external node via the head node, the intermediate node 1, the intermediate node 2, and the tail node.
  • the control management device may be, for example, a centralized controller, a network management device, or a flow analysis device that performs a flow analysis function.
  • the control and management device can be one device or a collection of multiple devices.
  • the control and management device may be a functional module integrated on a specific physical device, or it may refer to a physical device used to implement the functions implemented by the control and management device in this application.
  • the detection domain may be determined by the control and management device, and the detection domain is the detection range determined by the control and management device; it may also be configured on each forwarding device in the detection domain to form a detection domain. .
  • the network nodes located between the head node and the tail node of the detection domain are intermediate nodes, such as intermediate node 1 and intermediate node 2 in FIG. 1.
  • control and management equipment can deploy flow detection technology on each node in the detection domain to detect the transmission delay and packet loss in the detection domain.
  • the transmission delay of the detection domain may include the end-to-end transmission delay between the head node and the tail node.
  • Each node in the detection domain can periodically perform a delay detection operation. Specifically, in a flow-following detection cycle, the head node can select a message from the received packets for coloring, and the head node can add flow-following detection information indicating the detection of transmission delay to the message, and indicate The time stamp T1 of the time when the head node receives the message is reported to the control management device. After the tail node in the detection domain receives the message, it can forward the message to an external node and instruct the tail node to use the message. The time stamp T2 of the time forwarded to the external node is reported to the control management device.
  • the control and management device can calculate the end-to-end transmission delay of the detection domain in the flow-following detection period as T2-T1 according to the timestamp T1 reported by the head node and the timestamp T2 reported by the tail node.
  • the head node selects a message for coloring, it can color the message according to the characteristics of the message, for example, coloring a message that specifies quintuple information.
  • the quintuple information may include a source Internet Protocol (IP) address, a destination IP address, a protocol type, a source port number, and a destination port number.
  • IP Internet Protocol
  • the head node can alternately color the packets in the service flow according to certain rules, and report the information of the colored packets to the control and management device .
  • the tail node calculates the information of the dyed message received in the flow-following detection period, and reports the information to the control and management device.
  • the control and management device determines the packet loss of the packet flow in the detection domain according to the information reported by the head node and the tail node. For example, the head node dyes ten packets in a flow detection period, and reports the number of dyed packets (that is, 10) to the control and management device.
  • the tail node only receives nine dyed packets in the flow detection period, and the tail node reports the number of received dyed packets (ie 9) to the control and management device according to the head node and tail node.
  • the quantity can determine that packet loss occurred during the transmission of the service flow in the detection domain.
  • the flow detection technology has certain limitations. Specifically, the detection domain can only deploy one kind of bearer protocol. If the detection domain deploys multiple bearer protocols, the flow detection technology cannot be used for performance detection, for example, the flow detection technology cannot be used for end-to-end performance detection. This is because the packet encapsulation formats corresponding to different bearer protocols are different.
  • the flow detection information carried in the packet will be stripped. That is, the flow detection information cannot be transmitted in the entire detection domain.
  • the node that has not received the flow-following detection information will not perform the corresponding flow-following detection operation.
  • the deployment of a certain bearer protocol in the detection domain can also be regarded as the deployment of a network supporting the bearer protocol in the detection domain.
  • the deployment of the detection domain is based on the Internet Protocol version 6 segment routing (Segment Routing Internet Protocol Version 6, SRv6) protocol, which means that the SRv6 network is deployed in the detection domain.
  • FIG. 2 is a schematic diagram of an exemplary application scenario provided by an embodiment of the application.
  • Figure 2 shows a service function chain (SFC) scenario of the SRv6 protocol.
  • SFC service function chain
  • the SRv6 network is deployed between the ingress (provider edge, PE) equipment ingress (provider edge, PE) equipment and the egress (egress) PE equipment egress PE, and the service function forwarder (SFF) equipment
  • An Internet Protocol Version 4 (IPv4) network is deployed between the SFF and the service function (SF) equipment SF.
  • the customer edge (CE) device CE1 sends an IPv4 packet to the user network edge device CE2, and the packet passes through the SF device during the forwarding process.
  • the network between the ingress PE and the egress PE can be designated as the detection domain, and the flow detection technology is used to detect the performance of the detection domain.
  • the limitations of the flow detection technology are introduced to the process of packet transmission in the detection domain.
  • Step 1 After receiving the IPv4 packet from CE1, the ingress PE re-encapsulates the IPv4 packet into an SRv6 packet, and encapsulates the flow detection information into the SRv6 packet to indicate the node that received the flow detection information Perform a flow detection operation.
  • the SRv6 message may carry related information of the service function chain, such as service function path (service function path, SFP), and for example, data of the service function chain.
  • service function path service function path
  • data of the service function chain data of the service function chain.
  • the relevant information of the SFC may be carried in an SFC header.
  • the SFC header may be carried in a segment routing header (segment routing header, SRH).
  • SID-1 may be included in the SRH of SRv6.
  • SID-1 is the segment identifier (SID) of the service function device SF, that is, it indicates that the SRv6 message is passed through the SF during the forwarding process.
  • the SRv6 message can be forwarded to the SF through the SFF.
  • SID-1 can also be used to identify the type of service chain. Specifically, SID-1 can be used to identify a dynamic service chain or a static service chain.
  • SID-1 is used to identify the static service chain. If not all service flows are forwarded using the same tunnel, for example, different service flows are forwarded through different tunnels, SID-1 is used to identify the dynamic service chain.
  • Step 2 Ingress PE sends the encapsulated SRv6 message to SFF.
  • Step 3 The SFF re-encapsulates the received SRv6 message to obtain an IPv4 message, and sends the IPv4 message to the SF.
  • the SFF can strip the SFC header of the SRv6 message, and re-encapsulate the SRv6 message into an IPv4 message and send it to the SF.
  • the SFF may also cache the SFC header locally, because the SFC headers corresponding to different service flows may be different. If the aforementioned SID-1 identifies a static service chain, the SFF does not need to cache the SFC, because in this case, the SFC headers corresponding to all service flows are the same, and the SFC headers can be configured in the SFF by static configuration.
  • Step 4 The SF performs corresponding processing based on the received IPv4 message, and returns the IPv4 message to the SFF after processing.
  • the SF processes the IPv4 message, for example, it may perform security inspection on the IPv4 message to determine whether the IPv4 message is an attack message.
  • Step 5 The SFF re-encapsulates the received IPv4 message into an SRv6 message, and sends the SRv6 message to the egress PE.
  • the SRv6 message sent by the SFF to the egress PE does not include the flow detection information.
  • SFF When SFF re-encapsulates an IPv4 packet into an SRv6 packet, the SFC header needs to be encapsulated into the SRv6 packet. Therefore, SFF can obtain the corresponding SFC header. Specifically, if the aforementioned SID-1 identifies the dynamic service chain, the SFF caches the SFC header corresponding to the IPv4 packet when performing the aforementioned step 3. Therefore, the SFF can obtain the SFC header cached in step 3, and based on the SFC header Re-encapsulate the IPv4 packet into an SRv6 packet. If the aforementioned SID-1 identifies a static service chain, it means that all service messages use the same SFC header. In this case, SFF can obtain the SFC header statically configured on the SFF, and use the IPv4 header according to the obtained SFC header. The message is re-encapsulated into an SRv6 message.
  • Step 6 The egress PE re-encapsulates the received SRv6 message into an IPv4 message and sends it to CE2.
  • the SRH of the SRv6 message sent by the SFF to the egress PE may include End.DT4 SID.
  • the End.DT4 SID is used to identify the layer 3 virtual private network (layer3 virtual private network, L3VPN).
  • L3VPN layer3 virtual private network
  • the flow-following detection information is not transmitted in the entire detection domain. This is because in step 3, when the SFF re-encapsulates the received SRv6 message, the flow-following detection information in the SRv6 message is stripped off. In other words, none of the nodes between the SFF and the egress PE receives the flow-following detection information, and therefore, it is impossible to perform corresponding detection operations based on the flow-following detection information.
  • FIG. 2 is only shown for the convenience of understanding, and it does not constitute a limitation to the embodiments of the present application.
  • an IPv6 network or a virtual local area network (VLAN), or a multi-protocol label switching (Multi Protocol Label Switching, MPLS) network, or a generic routing encapsulation (generic) network may be deployed between the SFF and the SF in some embodiments.
  • Routing encapsulation, GRE) protocol network, or network service header (network service header, NSH) protocol network is not specifically limited in the embodiment of the present application.
  • SFF needs to re-encapsulate the SRv6 packet to obtain an IPv6 packet; in the aforementioned step 4, the packet received by the SFF is also an IPv6 packet; the aforementioned step The SFF in 5 re-encapsulates the received IPv6 message into an SRv6 message, and sends the SRv6 message to the egress PE.
  • step 3 SFF needs to re-encapsulate the SRv6 message to obtain a VLAN-encapsulated message; in step 4, the message received by SFF is also VLAN-encapsulated Message; In the foregoing step 5, the SFF re-encapsulates the received VLAN-encapsulated message into an SRv6 message, and sends the SRv6 message to the egress PE.
  • SFF needs to re-encapsulate the SRv6 message to obtain an MPLS message; in the aforementioned step 4, the message received by the SFF is also an MPLS message; The SFF in 5 re-encapsulates the received MPLS packet into an SRv6 packet, and sends the SRv6 packet to the egress PE.
  • SFF needs to re-encapsulate the SRv6 message to obtain a GRE message; in the aforementioned step 4, the message received by the SFF is also a GRE message; the aforementioned step The SFF in 5 re-encapsulates the received GRE message into an SRv6 message, and sends the SRv6 message to the egress PE.
  • the SFF needs to re-encapsulate the SRv6 message to obtain the NSH message; in the aforementioned step 4, the message received by the SFF is also an NSH message; the aforementioned step The SFF in 5 re-encapsulates the received NSH message into an SRv6 message, and sends the SRv6 message to the egress PE.
  • FIG. 3 is a schematic diagram of another exemplary application scenario provided by an embodiment of the application.
  • Figure 3 is a schematic diagram of a cross-domain VPN scenario.
  • PE1 and autonomous system boundary router (ASBR) ASBR1 belong to autonomous domain 100 (ie AS100), ASBR1 is also the PE device of AS 100, L3VPN is deployed in AS 100, and MPLS network or SR-MPLS network is deployed in AS 100.
  • ASBR1 and ASBR2 belong to AS 200, ASBR2 is also a PE device of AS 200, L3VPN is deployed in AS 200, and MPLS network or SR-MPLS network is deployed in AS 200.
  • ASBR1 regards ASBR2 as a CE device connected to itself, and ASBR2 also regards ASBR1 as a CE device connected to itself.
  • ASBR1 creates the VPN instance, it advertises IPv4 routes to ASBR2 through the External Border Gateway Protocol (EBGP).
  • EBGP advertises IPv4 routes to ASBR1.
  • the network between PE1 and PE2 can be designated as the detection domain, and the flow detection technology is used to detect the performance of the detection domain.
  • the limitations of the flow detection technology are introduced to the process of packet transmission in the detection domain.
  • Step 1 CE3 sends an IPv4 packet to PE1.
  • Step 2 After PE1 receives the IPv4 packet from PE1, it encapsulates the IPv4 packet into an MPLS packet, and encapsulates the flow detection information into the MPLS packet to instruct the node that has received the flow detection information to execute the follow-up Flow detection operation.
  • the MPLS packet also carries the public network label and the L3VPN private network label.
  • Step 3. PE1 sends the MPLS packet to ABSR1.
  • Step 4. ABSR1 re-encapsulates the received MPLS packet into an IPv4 packet and sends it to ABSR2.
  • ABSR1 When ABSR1 re-encapsulates the MPLS message, it strips off the flow detection information in the MPLS message. In other words, the IPv4 message sent by ABSR1 to ABSR2 does not include flow detection information.
  • Step 5 ASBR2 receives the IPv4 message sent by ASBR1, and re-encapsulates the IPv4 message to obtain an MPLS message including a private network label and a public network label.
  • Step 6 ASBR2 sends the re-encapsulated MPLS packet to PE2, and the MPLS packet sent by ASBR2 to PE2 does not include flow-following detection information.
  • Step 7 PE2 re-encapsulates the MPLS packet into an IPv4 packet and sends it to CE4.
  • the flow-following detection information is not transmitted in the entire detection domain. This is because in step 4, when ABSR1 re-encapsulates the received MPLS packet, the flow-following detection information in the MPLS packet is stripped. In other words, none of the nodes in the AS 200 received the flow-following detection information, and therefore, it is impossible to perform corresponding detection operations based on the flow-following detection information.
  • the embodiment of the present application provides a packet processing method based on flow detection, which can also use flow detection technology to perform performance detection when multiple bearer protocols are deployed in the detection domain.
  • FIG. 4 is a signaling interaction diagram of a packet processing method based on flow detection according to an embodiment of the application.
  • the method 100 shown in FIG. 4 may be implemented by the following S101-S108, for example.
  • the ingress PE receives packet 1 from CE1, and packet 1 is an IPv4 packet.
  • the message 1 is an IPv4 message, that is, the message 1 is a message encapsulated according to the IPv4 protocol.
  • the ingress PE re-encapsulates the message 1 to obtain the message 2.
  • the message 2 is an SRv6 message, and the message 2 includes the flow detection information 1.
  • the ingress PE serves as the head node of the detection domain, and when re-encapsulating the message 1, the flow detection information 1 is added to the message header to obtain the message 2.
  • the flow detection information 1 is used to indicate the performance parameters of the detection domain.
  • the detection domain includes the network between the ingress PE and the egress PE.
  • the flow-following detection information 1 may be iFIT flow-following detection information or iOAM flow-following detection information.
  • S104 SFF re-encapsulates the received message 2 to obtain message 3, message 3 is an IPv4 message, and message 3 includes flow detection information 1.
  • Message 3 is a message encapsulated according to the IPv4 protocol.
  • SFF re-encapsulates message 2 to obtain message 3, it does not simply strip the flow detection information 1 from message 2, but encapsulates the flow detection information 1 obtained from message 2 into message 3. .
  • the flow detection information 1 can be added to the header of the message, so as to obtain the message 3 including the flow detection information 1.
  • S105 SFF sends message 3 to SF.
  • the SF sends the message 4 obtained according to the message 3 to the SFF, and the message 4 includes the flow detection side information 1.
  • the SF After receiving the message 3, the SF processes the message 3 accordingly, and then, the SF obtains the message 4 according to the message 3, and sends the message 4 to the SFF. Specifically, when the SF obtains the message 4 according to the message 3 in a specific implementation, for example, the SF may modify the source media access control (MAC) address or the destination MAC address in the message 3, so that Get message 4.
  • the message 4 is an IPv4 message, and the message 4 includes flow detection information 1.
  • S107 SFF obtains message 5 according to message 4.
  • SFF After receiving message 4, SFF re-encapsulates message 4 according to the SRv6 protocol.
  • the flow detection information 1 in the message 4 is added to the message that is re-encapsulated according to the SRv6 protocol, so that the message 5 is obtained.
  • the SFF adds the flow detection information 1 to the header of the message that is re-encapsulated according to the SRv6 protocol, thereby re-obtaining the message 5.
  • the SFF sends the message 5 to the egress PE.
  • both the egress PE and the nodes between the egress PE and the SFF can receive the message 5 including the flow detection information 1.
  • the flow detection information 1 can be transmitted in the entire detection domain. Therefore, the nodes that receive the flow detection information 1 can perform flow detection operations, so that the SRv6 protocol and IPv4 are deployed in the detection domain. In the case of these two bearer protocols, the flow detection technology can also be used to perform performance detection on the detection domain.
  • the detection domain shown in FIG. 2 may include domain A and domain B, where the bearer protocol deployed in domain A is the SRv6 protocol, and the bearer protocol deployed in domain B is the IPv4 protocol.
  • Domain A includes ingress PE and SFF, or domain A includes egress PE and SFF, and domain B includes SFF and SF.
  • Figure 5a shows a schematic structural diagram of a possible SRv6 message.
  • the SRv6 message shown in Figure 5a includes the ETH field, IPv6 Basic Header, SRH, and Payload.
  • the ETH field is used to carry the Layer 2 Ethernet header, and the ETH can carry the source MAC address, destination MAC address, and protocol type.
  • IPv6 Basic Header is an IPv6 basic header, and the specific fields contained therein will not be described in detail here.
  • the SRH field includes SRH Basic Header, Segment List, and Option type length value (type length value, TLV).
  • SRH Basic Header is the basic extension header of SRH, and the specific fields contained therein will not be described in detail here.
  • the Segment List is used to carry a list of segment identifiers indicating the packet forwarding path.
  • Option TLV can be used as an extension field. In this embodiment of the application, the aforementioned flow detection information 1 may be carried in Option TLV.
  • Figure 5b shows the structure of an SRv6 message when the flow-following detection information 1 is iFIT flow-following detection information.
  • a flow instruction indicator (FII) field a flow instruction header (FIH) field, and a flow instruction extension header (FIEH) field constitute iFIT information.
  • FII flow instruction indicator
  • FIH flow instruction header
  • FIEH flow instruction extension header
  • the FII field is mainly used to identify several bytes of data after the field as IFIT information.
  • the FII field may include the following field information, for example:
  • Type field used to identify the iFIT detection head
  • the Length field is used to identify the length of the FIH field and the FIEH field;
  • the Reserved field is a reserved field.
  • the FIH field can also be referred to as a flow detection header or a flow detection header. This field is mainly used to carry information related to IFIT detection. For example, the following field information can be included:
  • Flow ID (English: Flow ID), a globally unique ID assigned to each IFIT detection flow;
  • L flag bit packet loss (in English: packet loss) detection dyeing mark, for example: the value of the L flag bit is "1" means packet loss is collected, and "0" means no packet loss is collected.
  • the D flag bit measures the dyeing mark. For example, the value of the D flag bit is "1", which means the time stamp is collected, and "0" means that the time stamp is not collected.
  • Header type indicator which marks the range of nodes that need to send IFIT detection results and the range of detection content. For example, different tag values can be used to distinguish whether it is for path nodes with iFIT capability in addition to detecting nodes at both ends Check whether the FIEH field is valid, etc.
  • the R flag can be used as a reserved flag.
  • the FIEH field can also be referred to as the flow extension detection header or the extension flow detection header.
  • this field is mainly used to carry other iFIT detection related information.
  • the following field information can be included:
  • the V flag bit is used to mark the reverse flow (English: reverse flow). For example, the value of the V flag bit is “0" to indicate that the current flow is a forward flow, and the receiving end can automatically create a reverse flow; “1" means The current flow is a reverse flow, and the receiving end no longer automatically creates a reverse flow.
  • the V flag is an optional field, which is not shown in Figure 1;
  • Period (English: Period). Different values indicate different detection periods.
  • the detection period can be, for example, 1s, 10s, 30s, 1min, or 10min.
  • Figure 5c shows the structure of an SRv6 message when the flow-following detection information 1 is iOAM flow-following detection information.
  • the iOAM flow detection information includes the SRH-TLV-Type field, the iOAM-Type field, the iOAM HDR LEN field, the iOAM Option and Data Space field, and the RESERVED field.
  • the SRH-TLV-Type field is used to identify iOAM encapsulation, that is, it is used to identify that several bytes of data after this field are iOAM information.
  • the iOAM-Type field is used to indicate the iOAM type.
  • the iOAM HDR LEN field is used to identify the length of the iOAM header.
  • the iOAM Option and Data Space field is an iOAM option and data field, which is used to carry instruction information for instructing a node to perform a corresponding flow detection operation.
  • the RESERVED field is a reserved field.
  • FIG. 6a shows a schematic diagram of a possible IPv4 packet structure.
  • the IPv4 message includes the ETH field, IPv4 Header and Payload.
  • the flow detection information 1 can be located in the IPv4 Header.
  • the flow detection information 1 may be located in the options field of the IPv4 header. in:
  • the ETH field is used to carry the Layer 2 Ethernet header, and the ETH can carry the source media access control (MAC) address, destination MAC address, and protocol type.
  • MAC media access control
  • the flow-following detection information 1 shown in FIG. 6a may be iFIT flow-following detection information, or iOAM flow-following detection information.
  • iFIT flow detection information For the iFIT flow detection information, refer to the description part of the iFIT flow detection information in FIG. 5b, which is not detailed here.
  • FIG. 6b shows the structure of the IPv4 message when the flow detection information 1 is iOAM flow detection information.
  • the iOAM flow detection information can be located in the options field of the IPv4 Header.
  • the iOAM flow detection information includes the Option Type field, the Option Length field, the RESERVED field, the iOAM-Type field, and the Option Data field. in:
  • the Option Type field is used to indicate the option header of the iOAM encapsulation type.
  • the Option Length field is used to indicate the length of the entire iOAM header.
  • RESERVED is a reserved field.
  • the iOAM-Type field is used to indicate the iOAM type.
  • the Option Data field is an iOAM option and data field, which is used to carry instruction information for instructing a node to perform a corresponding flow detection operation.
  • Figure 6c shows a schematic diagram of another possible IPv4 packet structure.
  • the IPv4 message includes the ETH field, IPv4 Header, Transmission Control Protocol (TCP)/User Datagram Protocol (UDP), Magic Number (probe mark) field, and flow detection header And Payload.
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • Magic Number probe mark
  • the magic number field is used to indicate that the next several bytes of data are flow detection data, and the magic number field may include 8 bytes, for example.
  • the magic number field may correspond to the FII field shown in FIG. 5b, and the flow detection header may include the FIH field and the FIEH field shown in FIG. 5b, for example.
  • the FII field, the FIH field, and the FIEH field reference may be made to the description of FIG. 5b above, which will not be described in detail here.
  • the magic number field and the specific encapsulation form of the flow detection header are not specifically limited in this embodiment of the application.
  • the magic number field may correspond to that shown in FIG. 5c, for example.
  • the SRH-TLV-Type field, the flow detection header may include, for example, the iOAM-Type field, the iOAM HDR LEN field, the iOAM Option and Data Space field, and the RESERVED field shown in FIG. 5c.
  • FIG. 7 is a signaling interaction diagram of a packet processing method based on flow detection according to an embodiment of the application.
  • the method 200 shown in FIG. 7 may be implemented through the following S201-S207, for example.
  • PE1 receives packet 6 from CE3, and packet 6 is an IPv4 packet.
  • PE1 re-encapsulates message 6 into message 7, message 7 is an MPLS message, and message 7 includes flow detection information 2.
  • the message 7 includes the public network label and the L3VPN private network label.
  • the detection domain includes the network between PE1 and PE2.
  • PE1 adds the flow detection information 2 to the header of the message when re-encapsulating the message 6, thereby obtaining the message 7.
  • the flow detection information 2 can be iFIT flow detection information or iOAM flow detection information.
  • the ABSR1 re-encapsulates the received message 7 to obtain the message 8.
  • the message 8 is an IPv4 message, and the message 8 includes the flow detection information 2.
  • Message 8 is a message encapsulated according to the IPv4 protocol.
  • ABSR1 re-encapsulates message 7 to obtain message 8, instead of simply stripping the flow detection information 2 from message 7, it encapsulates the flow detection information 2 obtained from message 7 into message 8. .
  • the flow detection information 2 can be added to the header of the message, so as to obtain the message 8 including the flow detection information 2.
  • ABSR1 sends message 8 to ABSR2.
  • ABSR2 re-encapsulates the received message 8 to obtain message 9.
  • the message 9 is an MPLS message, and the message 9 includes flow detection information 2.
  • Message 9 is a message encapsulated according to the MPLS protocol.
  • ABSR2 re-encapsulates message 8 to obtain message 9, instead of simply stripping the flow detection information 2 from message 8, it encapsulates the flow detection information 2 obtained from message 8 into message 9. .
  • the flow detection information 2 may be added to the header of the message, so as to obtain the message 9 including the flow detection information 2.
  • the structure of the message 9 is the same as the structure of the message 7, and you can refer to the description of FIG. 8a and FIG. 8b below.
  • ABSR2 sends message 9 to PE2.
  • the flow-following detection information 2 can be transmitted in the entire detection domain. Therefore, all nodes that receive the flow detection information 2 can perform flow detection operations, so that when two bearer protocols, MPLS and IPv4, are deployed in the detection domain, flow detection technology can also be used to perform the flow detection operation. Perform performance testing in the detection domain.
  • the network domain shown in FIG. 3 may include domain C, domain D, and domain E, where the bearer protocol deployed in domain C is the MPLS protocol, and the bearer protocol deployed in domain D is IPv4 protocol, the bearer protocol deployed in domain E is the MPLS protocol.
  • Domain C includes PE1 and ABSR1
  • domain D includes ABSR1 and ABSR2
  • domain E includes ABSR2 and PE2.
  • Fig. 8a shows a schematic diagram of a possible MPLS packet structure.
  • the MPLS packet shown in Figure 8a includes an ETH field, an SR Label field, a VPN Label field, a flow detection header, and a Payload. in:
  • the ETH field is used to carry the Layer 2 Ethernet header, and the ETH can carry the source MAC address, destination MAC address, and protocol type.
  • SR Label is used to carry public network labels.
  • VPN Label is used to carry private network labels.
  • the flow detection header can be used to carry the iFIT flow detection information shown in FIG. 8b, and can also be used to carry the iOAM flow detection information shown in FIG. 8c.
  • the iFIT flow detection information shown in FIG. 8b includes: FII field, FIH field and FIEH field.
  • the FII field is mainly used to identify several bytes of data after the field as IFIT information.
  • the FII field may include the following field information, for example:
  • Flow instruction indicator label (English: FII Label), which can be configured with a default value to identify the iFIT detection flow;
  • the priority EXP flag bit can be determined according to part of the relevant information in the outer MPLS label header;
  • the S flag is used to mark whether it is the bottom of the stack, for example, a value of 1 is the bottom of the stack, and a value of 0 is the bottom of the stack;
  • Time to live (time to live, TTL) flag bit can also be determined according to part of the relevant information in the outer MPLS label header.
  • the iOAM flow detection information shown in FIG. 8c includes: iOAM indicator label (Indicator Label) field, iOAM-Type field, iOAM HDR LEN field, IOAM Option and Data Space field, and RESERVED field. in:
  • the iOAM Indicator Label field is used to identify iOAM encapsulation, that is, it is used to identify that several bytes of data after this field are iOAM information.
  • the iOAM-Type field is used to indicate the iOAM type.
  • the iOAM HDR LEN field is used to identify the length of the iOAM header.
  • the iOAM Option and Data Space field is an iOAM option and data field, which is used to carry instruction information for instructing a node to perform a corresponding flow detection operation.
  • the RESERVED field is a reserved field.
  • FIG. 9 is a schematic flowchart of a packet processing method based on flow detection according to an embodiment of the application. The method will be described below with reference to FIG. 9.
  • the method 300 shown in FIG. 9 may be implemented through S301-S302, for example.
  • the first node receives the first message from the second node, the first message header of the first message includes first flow-following detection information, and the first message uses the first bearer protocol Packets to be encapsulated.
  • the first node obtains a second message according to the first message, the second message header of the second message includes the first flow detection information, and the second message is A message encapsulated using a second bearer protocol, where the first bearer protocol and the first and second bearer protocols are different bearer protocols.
  • S303 The first node forwards the second message to a third node.
  • the method 300 may be used to implement the steps performed by the SFF in the method 100 mentioned in the above embodiment, and the method 300 may also be used to perform the steps performed by the ABSR1 or the ABSR2 in the method 200 mentioned in the above embodiment.
  • the first node corresponds to the SFF shown in FIG. 2, and the second node corresponds to the ingress shown in FIG. 2.
  • the first message corresponds to the message 2 in the method 100
  • the first bearer protocol is the SRv6 protocol
  • the first flow detection information is the flow detection information 1 in the method 100.
  • the second message corresponds to message 3 in the method 100
  • the second bearer protocol is the IPv4 protocol.
  • the third node is the SF in method 100.
  • the first node corresponds to the SFF shown in FIG. 2 and the second node corresponds to the SF described in FIG. 2,
  • the first message corresponds to the message 4 in the method 100
  • the first bearer protocol is the IPv4 protocol
  • the first flow detection information is the flow detection information 1 in the method 100.
  • the second message corresponds to message 5 in method 100
  • the second bearer protocol is the SRv6 protocol
  • the third node corresponds to the egress PE shown in FIG. 2.
  • the first node corresponds to the ABSR1 shown in FIG. 3
  • the second node corresponds to the PE1 shown in FIG. 3
  • the first message corresponds to the method
  • the first bearer protocol is the MPLS protocol
  • the first flow-following detection information is the flow-following detection information 2 in the method 200.
  • the second message corresponds to message 8 in the method 200
  • the second bearer protocol is the IPv4 protocol.
  • the third node is ABSR2 in method 200.
  • the first node corresponds to the ABSR2 shown in FIG. 3
  • the second node corresponds to the ABSR1 shown in FIG. 3
  • the first message corresponds to the method In the packet 8 in 200
  • the first bearer protocol is the IPv4 protocol
  • the first flow-following detection information is the flow-following detection information 2 in the method 200.
  • the second message corresponds to message 9 in the method 200
  • the second bearer protocol is the MPLS protocol.
  • the third node is PE2 in method 200.
  • the first bearer protocol is IPv4, IPv6, MPLS, VLAN, GRE, NSH, or SRv6; and the second bearer protocol is IPv4, IPv6, or MPLS. , VLAN protocol, GRE protocol, NSH protocol or SRv6 protocol.
  • the first flow-following detection information is used to indicate performance parameters of a detection detection domain
  • the detection domain includes a first domain and a second domain
  • the second node belongs to the first domain
  • the third node belongs to the second domain
  • the first node is a cross-domain node of the first domain and the second domain.
  • the detection domain is the detection domain shown in FIG. 2, and the first domain may include ingress PE and SFF, which corresponds to the domain mentioned above A, the second domain can include SFF and SF, which corresponds to domain B mentioned above.
  • the first node corresponds to the SFF shown in FIG. 2
  • the second node corresponds to the ingress PE shown in FIG. 2
  • the third node corresponds to the SF shown in FIG. 2.
  • the first node may also be used to receive a third message returned by the third node, where the third message includes the first flow detection information, and the first
  • the third message is a message encapsulated using the second bearer protocol; the first node generates a fourth message according to the third message, and the fourth message includes the first flow-following detection Information, the fourth message is a message encapsulated using the first bearer protocol; the first node sends the first message to a next-hop node.
  • the third message mentioned here corresponds to the message 4 in the method 100
  • the first flow detection information corresponds to the flow detection information 1 in the method 100
  • the fourth message corresponds to the message 5 in the method 100.
  • the first bearer protocol is the IPv4 protocol
  • the second bearer protocol is the SRv6 protocol.
  • the first domain deploys an SRv6 network
  • the second domain deploys an IPv4 network
  • the first message is an SRv6 message carrying SFC information
  • the second message is an SRv6 message carrying SFC information.
  • the first field includes the ingress PE and SFF shown in Figure 2, that is, the first field corresponds to the aforementioned field A
  • the second field includes the SFF and SF shown in Figure 2, that is, the second field corresponds to the aforementioned Domain B.
  • the first domain deploys an IPv4 network
  • the second domain deploys an SRv6 network
  • the first message is an IPv4 message carrying SFC information
  • the second message is an IPv4 message carrying SFC information.
  • SRv6 message the first field includes the SFF and SF shown in Figure 2, that is, the first field corresponds to the aforementioned field B
  • the second field includes the SFF and egress PE shown in Figure 2, that is, the second field corresponds to the aforementioned Domain A.
  • the detection domain is the detection domain shown in FIG. 3.
  • the first domain deploys an MPLS network
  • the second domain deploys an IPv4 network
  • the first message is an MPLS message
  • the second message is an IPv4 message.
  • the first domain may include PE1 and ABSR1 shown in FIG. 3, that is, the first domain may correspond to the aforementioned domain C
  • the second domain may include ABSR1 and ABSR2 shown in FIG. 3, that is, the second domain may include the foregoing Mentioned domain D.
  • the first message may correspond to message 7 in method 200
  • the second message may correspond to message 8 in method 200.
  • the first domain deploys a three-layer virtual private network L3VPN.
  • the detection domain further includes a third domain
  • the third domain deploys an MPLS network
  • the third node is a cross-domain node of the second domain and the third domain.
  • the third domain may include ABSR2 and PE2 shown in FIG. 3, that is, the third domain may correspond to the aforementioned domain E, and in this case, the third node is ABSR2.
  • the third domain deploys L3VPN.
  • the first domain is a first autonomous system, and the first node is an ABSR of the first autonomous system; the third domain is a second autonomous system, and the third node is The ABSR of the second autonomous system. That is, the domain C and the domain D mentioned above are both autonomous systems, the first node corresponds to ASBR1 shown in FIG. 3, and the third node corresponds to ASBR2 shown in FIG. 3.
  • the first domain deploys an IPv4 network
  • the second domain deploys an MPLS network
  • the first domain deploys an MPLS network.
  • One message is an IPv4 message
  • the second message is an MPLS message.
  • the first domain may include ABSR1 and ABSR2 shown in FIG. 3, that is, the first domain corresponds to the aforementioned domain D
  • the second domain may include ABSR2 and PE2 shown in FIG. 3, that is, the second domain may Corresponds to the domain E mentioned above.
  • the first node may correspond to ABSR2 in method 200
  • the first message may correspond to message 8 in method 200
  • the second message may correspond to message 9 in method 200.
  • the second domain deploys L3VPN.
  • the first flow-following detection information includes: iFIT flow-following detection information, or iOAM flow-following detection information.
  • FIG. 10 is a schematic structural diagram of a first node provided by an embodiment of the present application.
  • the first node 1000 includes a transceiver unit 1001 and a processing unit 1002.
  • the transceiving unit 1001 is used to perform the transceiving operation performed by the SFF in the embodiment corresponding to the method 100;
  • the processing unit 1002 is used to perform other operations other than the transceiving operation performed by the SFF in the embodiment corresponding to the method 100.
  • the transceiving unit 1001 is configured to perform the transceiving operations performed by ABSR1 in the embodiment corresponding to the method 200; the processing unit 1002 is configured to perform other operations other than the transceiving operations performed by the ABSR1 in the embodiment corresponding to the method 200.
  • the transceiving unit 1001 is configured to perform the transceiving operations performed by ABSR2 in the embodiment corresponding to the method 200; the processing unit 1002 is configured to perform other operations other than the transceiving operations performed by the ABSR2 in the embodiment corresponding to the method 200.
  • the first node 1000 is the SFF in the method 100
  • the transceiver unit 1001 is used to perform the step of receiving the message 2 from the ingress PE and the step of sending the message 3 to the SF
  • the processing unit 1002 is used to execute the step of obtaining message 3 according to message 2.
  • FIG. 11 is a schematic structural diagram of a first node provided by an embodiment of the present application.
  • the first node 1100 includes a communication interface 1101 and a processor 1102 connected to the communication interface 1101.
  • the communication interface 1101 is used to perform the transceiving operations performed by the SFF in the embodiment corresponding to the method 100; the processor 1102 is used to perform other operations other than the transceiving operations performed by the SFF in the embodiment corresponding to the method 100.
  • the communication interface 1101 is used to perform the transceiving operation performed by ABSR1 in the embodiment corresponding to the method 200; the processor 1102 is used to perform other operations other than the transceiving operation performed by the ABSR1 in the embodiment corresponding to the method 200.
  • the communication interface 1101 is used to perform the transceiving operation performed by ABSR2 in the embodiment corresponding to the method 200; the processor 1102 is used to perform other operations other than the transceiving operation performed by the ABSR2 in the embodiment corresponding to the method 200.
  • the first node 1100 is the SFF in the method 100, then the communication interface 1101 is used to perform the step of receiving the message 2 from the ingress PE and the step of sending the message 3 to the SF; the processor 1102 is used to perform the step of obtaining message 3 according to message 2.
  • FIG. 12 is a schematic structural diagram of a first node provided by an embodiment of the present application.
  • the first node 1200 includes a memory 1201 and a processor 1202.
  • the memory 1201 is used to store program code; the processor 1202 is used to run instructions in the program code, so that the first node 1200 executes the steps performed by the SFF in the embodiment corresponding to the method 100, or causes the first node 1200 to execute the steps performed by SFF in the embodiment corresponding to the method 100.
  • the node 1200 executes the steps executed by the ABSR1 in the embodiment corresponding to the method 200, or causes the first node 1200 to execute the steps executed by the ABSR2 in the embodiment corresponding to the method 200.
  • the embodiments of the present application also provide a computer-readable storage medium that stores instructions in the computer-readable storage medium, which when run on a computer, causes the computer to execute the above method 100 in the corresponding embodiment
  • the steps performed by the SFF may cause the computer to execute the steps performed by ABSR1 in the embodiment corresponding to the method 200, or the computer may execute the steps performed by the ABSR2 in the embodiment corresponding to the method 200.
  • the disclosed system, device, and method can be implemented in other ways.
  • the device embodiments described above are merely illustrative, for example, the division of units is only a logical business division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or integrated. To another system, or some features can be ignored, or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
  • service units in the various embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.
  • the above-mentioned integrated unit can be realized in the form of hardware or software business unit.
  • the integrated unit is implemented in the form of a software business unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
  • the technical solution of the present application essentially or the part that contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , Including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods in the various embodiments of the present application.
  • the aforementioned storage media include: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disks or optical disks and other media that can store program codes. .
  • the services described in the present invention can be implemented by hardware, software, firmware, or any combination thereof.
  • these services can be stored in a computer-readable medium or transmitted as one or more instructions or codes on the computer-readable medium.
  • the computer-readable medium includes a computer storage medium and a communication medium, where the communication medium includes any medium that facilitates the transfer of a computer program from one place to another.
  • the storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例公开了一种基于随流检测的报文处理方法，第一节点接收到采用第一承载协议进行封装的第一报文之后，可以根据第一报文得到采用第二承载协议封装的第二报文。第一报文的第一报文头中包括第一随流检测信息，第二报文的报文头中也包括第一随流检测信息。由此可见，第一节点采用第二承载协议对第一报文进行重新封装时，不是将第一随流检测信息剥离，而是将第一随流检测信息添加到采用第二承载协议进行封装的报文中。因此，即使检测域中部署第一承载协议和第二承载协议，第一随流检测信息也不会随着因为报文被重新封装而被剥离，第一随流检测信息可以在整个检测域中传输。故而可以利用随流检测技术对检测域进行性能检测。

Description

一种基于随流检测的报文处理方法及装置
本申请要求于2020年4月24日提交中国知识产权局、申请号为202010332211.0、申请名称为“一种基于随流检测的报文处理方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信领域，尤其涉及一种基于随流检测的报文处理方法及装置。
背景技术
在数据通信网络中，可以采用随流检测技术检测数据通信网络的性能，例如，检测数据通信网络的时延和丢包。随流检测技术例如可以为随流信息遥测(in-situ flow information telemetry，iFIT)技术或者带内操作管理维护(inband operation administration and maintenance，iOAM)技术。
在一个网络中可以通过指定检测域确定需要执行随流检测的网络范围。检测域中的节点需要传输随流检测信息以实现随流检测。目前，若检测域中部署有多种承载协议，则无法利用随流检测技术检测该检测域的性能。因此，需要一种方案，可以解决上述问题。
发明内容
本申请实施例提供了一种基于随流检测的报文处理方法及装置，可以在检测域中部署有多种承载协议的情况下，也能利用随流检测技术进行性能检测。
第一方面，本申请实施例提供了一种基于随流检测的报文处理方法。目前，对于部署有多种承载协议的检测域，无法利用随流检测技术进行性能检测。这是因为不同承载协议对应的报文封装格式不同。当携带随流检测信息的报文在部署多种承载协议的检测域中传输时，一旦需要对报文重新封装。则报文中携带的随流检测信息会被剥离。故而，随流检测信息不能在整个检测域中传输，从而使得随流检测技术不能对该检测域进行性能检测。在本申请实施例中，检测域中的第一节点接收到来自第二节点的第一报文之后，可以根据第一报文得到第二报文。其中，第一报文的第一报文头中包括第一随流检测信息，第一报文是采用第一承载协议进行封装的报文。第一节点可以采用第二承载协议对第一报文进行重新封装，在对第一报文进行重新封装时，第一节点不是将第一随流检测信息剥离，而是将第一随流检测信息添加到采用第二承载协议进行封装的报文中，从而得到包括第一随流检测信息的第二报文。第一节点得到第二报文之后，可以将第二报文转发给第三节点，使得包含第一随流检测信息的第二报文继续在检测域中传输。由此可见，利用本申请实施例的方案，即使检测域中部署第一承载协议和第二承载协议，第一随流检测信息也不会随着因为报文被重新封装而被剥离，第一随流检测信息可以在整个检测域中传输。因此，即使检测域中部署第一承载协议和第二承载协议，也可以利用随流检测技术对检测域进行性能检测。
在一种实现方式中，第一承载协议为IPv4协议、IPv6协议、MPLS协议、VLAN协议、GRE协议、NSH协议或者互联网协议第6版分段路由SRv6协议；第二承载协议为IPv4协议、IPv6协议、MPLS协议、VLAN协议、GRE协议、NSH协议或者SRv6协议，第一承载协议和第二承载协议不同。
在一种实现方式中，所述第一随流检测信息用于指示检测检测域的性能参数，所述检 测域包括第一域和第二域，所述第二节点属于所述第一域，所述第三节点属于所述第二域，所述第一节点为所述第一域和所述第二域的跨域节点。由此可见，在本申请实施例中，第一节点作为第一域和第二域的跨域节点，可以在携带第一随流检测信息的第一报文跨第一域和第二域传输时，使得第一随流检测信息不被剥离，从而使得第一随流检测信息可以在整个检测域中传输。
在一种实现方式中，所述第一节点为业务功能代理SF proxy，所述第三节点为业务功能SF设备。
在一种实现方式中，当第一节点为SF proxy，第三节点为SF设备时，第一节点还可以接收所述第三节点返回的第三报文，所述第三报文包括所述第一随流检测信息，所述第三报文为采用所述第二承载协议进行封装的报文；所述第一节点根据所述第三报文，生成第四报文，所述第四报文包括所述第一随流检测信息，所述第四报文为采用所述第一承载协议进行封装的报文；所述第一节点向下一跳节点发送所述第一报文。在这种场景下，可以使得第一报文在传输过程中经过SF设备，也不会丢失第一随流检测信息，使得第一随流检测信息可以继续向下一跳节点传输。
在一种实现方式中，所述第一域部署SRv6网络，所述第二域部署IPv4网络，所述第一报文为携带业务链SFC信息的SRv6报文，所述第二报文为携带所述SFC信息的IPv4报文。对于这种情况，可以在检测域中部署SRv6网络和IPv4网络的情况下，也能利用随流检测技术对检测域进行性能检测。
在一种实现方式中，所述第一域部署IPv4网络，所述第二域部署SRv6网络，所述第一报文为携带SFC信息的IPv4报文，所述第二报文为携带SFC信息的SRv6报文。对于这种情况，可以在检测域中部署SRv6网络和IPv4网络的情况下，也能利用随流检测技术对检测域进行性能检测。
在一种实现方式中，所述第一域部署MPLS网络，所述第二域部署IPv4网络，所述第一报文为MPLS报文，所述第二报文为IPv4报文。对于这种情况，可以在检测域中部署MPLS网络和IPv4网络的情况下，也能利用随流检测技术对检测域进行性能检测。
在一种实现方式中，所述第一域部署三层虚拟专用网络L3VPN。
在一种实现方式中，所述检测域还包括第三域，所述第三域部署MPLS网络，所述第三节点为所述第二域和所述第三域的跨域节点。对于这种情况，可以在检测域中部署MPLS网络和IPv4网络的情况下，也能利用随流检测技术对检测域进行性能检测。
在一种实现方式中，所述第三域部署L3VPN。
在一种实现方式中，所述第一域为第一自治系统AS，所述第一节点为所述第一AS的自治系统边界路由器ABSR；所述第三域为第二AS，所述第三节点为所述第二AS的ABSR。
在一种实现方式中，所述第一域部署IPv4网络，所述第二域部署MPLS网络，所述第一报文为IPv4报文，所述第二报文为MPLS报文。对于这种情况，可以在检测域中部署MPLS网络和IPv4网络的情况下，也能利用随流检测技术对检测域进行性能检测。
在一种实现方式中，所述第二域部署L3VPN。
在一种实现方式中，所述第一随流检测信息包括：iFIT随流检测信息，或者，iOAM随流检测信息。
第二方面，本申请实施例提供了一种第一节点，包括：通信接口；和与所述通信接口连接的处理器；根据所述通信接口和所述处理器，所述第一节点用于执行以上第一方面任一项所述的方法。
第三方面，本申请实施例提供了一种第一节点，所述第一节点包括存储器和处理器；所述存储器，用于存储程序代码；所述处理器，用于运行所述程序代码中的指令，使得所述第一节点执行以上第一方面任一项所述的方法。
第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得所述计算机执行以上第一方面任意一项所述的方法。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种网络架构示意图；
图2为本申请实施例提供的一种示例性应用场景示意图；
图3为本申请实施例提供的又一种示例性应用场景示意图；
图4为本申请实施例提供的一种基于随流检测的报文处理方法的信令交互图；
图5a为本申请实施例提供的一种可能的SRv6报文的结构示意图；
图5b为本申请实施例提供的又一种可能的SRv6报文的结构示意图；
图5c为本申请实施例提供的又一种可能的SRv6报文的结构示意图；
图6a为本申请实施例提供的一种可能的IPv4报文的结构示意图；
图6b为本申请实施例提供的又一种可能的IPv4报文的结构示意图；
图6c为本申请实施例提供的又一种可能的IPv4报文的结构示意图；
图7为本申请实施例提供的一种基于随流检测的报文处理方法的信令交互图；
图8a为本申请实施例提供的一种可能的MPLS报文的结构示意图；
图8b为本申请实施例提供的一种iFIT随流检测信息的结构示意图；
图8c为本申请实施例提供的一种iOAM随流检测信息的结构示意图；
图9为本申请实施例提供的一种基于随流检测的报文处理方法的流程示意图；
图10为本申请实施例提供的一种第一节点的结构示意图；
图11为本申请实施例提供的一种第一节点的结构示意图；
图12为本申请实施例提供的一种第一节点的结构示意图。
具体实施方式
本申请实施例提供了一种基于随流检测的报文处理方法，可以在检测域中部署有多种承载协议的情况下，也能利用随流检测技术进行性能检测。
为方便理解，首先对随流检测技术进行简单介绍。
随流检测技术可以利用报文中携带的随流检测信息对网络中的业务流进行特征标记，该特征标记也可称之为染色。业务流经过的节点将收集到的时间戳、包数等数据上报给控 制管理设备，以供控制管理设备基于上报的数据进一步计算网络时延和丢包情况。
在一个网络中可以通过指定检测域确定需要执行随流检测的网络范围，通常所述检测域中的节点需要传输随流检测信息以实现随流检测，并将执行所述随流检测后获取的相应信息发送至控制管理设备。所述检测域的检测范围可以基于多种方式确定，例如，可以基于网络场景确定，如指定网络中的核心网部分作为所述检测域；或者，可以基于业务类型确定，如为视频业务和语音业务指定不同范围的检测域等。检测域中包括三类节点，具体为头节点(英文：head node)、尾节点(英文：end node)和逐跳的路径节点(英文：path node)。其中，逐跳的路径节点也可以称之为中间节点。所述头节点、尾节点和路径节点例如可以是网络中的相应网络节点。对于一条业务流而言，在所述检测域指定的检测范围内传输所述业务流的第一个网络节点，可以作为传输所述业务流的头节点。在所述检测域指定的检测范围内传输所述业务流的最后一个网络节点，可以作为传输所述业务流的尾节点。在所述头节点和所述尾节点之间传输所述业务流的各个节点即为逐跳的路径节点。随流检测信息可以由头节点添加，并在尾节点剥离。
接下来，对随流检测可能的网络架构进行介绍。参见图1，该图为本申请实施例提供的一种网络架构示意图。网络100包括控制管理设备和多个网络节点。所述多个网络节点之间通过通信链路连接，用于传输业务流。如图1所示，检测域中的头节点、中间节点1、中间节点2和尾节点通过通信链路连接。检测域中除了包括图示所述的各节点外，还可以包括其他未示出的节点。尾节点还可以通过通信链路和外部节点连接。头节点可以从其它设备处接收业务流，该业务流可以经由头节点、中间节点1、中间节点2和尾节点到达外部节点。控制管理设备例如可以是集中控制器，可以是网管，也可以是执行流量分析功能的流量分析设备。控制管理设备可以是一个设备，也可以是指多个设备的集合。控制管理设备可以是功能模块，集成在具体的物理设备上，也可以是指用于实现本申请有控制管理设备所述实现的功能的物理设备。
在本申请中，可以由控制管理设备确定检测域，所述检测域是所述控制管理设备确定的检测范围；也可以是在检测域中的各转发设备上分别进行配置，从而形成一个检测域。在所述检测域中的传输路径上，位于检测域的头节点和尾节点之间的网络节点是中间节点，例如图1中的中间节点1和中间节点2。
目前，控制管理设备可以在检测域中的各节点上部署随流检测技术，以检测检测域的传输时延和丢包。
检测域的传输时延可以包括头节点到尾节点之间的端到端传输时延。检测域中的各节点可以周期性执行时延检测操作。具体地，在一个随流检测周期内，头节点可以从接收的报文中选择一条报文进行染色，头节点可以在该报文中添加指示检测传输时延的随流检测信息，并将指示头节点接收该报文的时间的时间戳T1上报给控制管理设备，检测域中的尾节点接收到该报文之后，可以将该报文转发给外部节点，并将指示尾节点将该报文转发给外部节点的时间的时间戳T2上报给控制管理设备。控制管理设备则可以根据头节点上报的时间戳T1和尾节点上报的时间戳T2，计算得到检测域在该随流检测周期的端到端传输时延为T2-T1。头节点在选择报文进行染色时，可以根据报文的特征对报文进行染色，例如，对指定五元组信息的报文进行染色。其中，五元组信息可以包括源互联网协议(Internet  Protocol，IP)地址、目的IP地址、协议类型、源端口号和目的端口号。
检测域的丢包测量在具体实现时，在一个随流检测周期内，头节点可以按照一定规则对业务流中的报文进行交替染色，并将被染色的报文的信息上报给控制管理设备。尾节点计算在该随流检测周期内接收到的被染色的报文的信息，并将该信息上报给控制管理设备。控制管理设备根据头节点和尾节点上报的信息，确定报文流在检测域的丢包情况。例如，头节点对一个随流检测周期内的十条报文进行染色，并将被染色的报文数量(即10)上报给控制管理设备。尾节点在该随流检测周期内仅接收到九条染色的报文，尾节点将接收到的被染色报文的数量(即9)上报给控制管理设备控制管理设备根据头节点和尾节点上报的数量则可以确定该业务流在检测域中传输的过程中的发生了丢包。
目前，随流检测技术存在一定的局限性。具体地，检测域只能部署一种承载协议，若检测域部署多种承载协议，则无法利用随流检测技术进行性能检测，例如无法利用随流检测技术进行端到端性能检测。这是因为不同承载协议对应的报文封装格式不同。当携带随流检测信息的报文在部署多种承载协议的检测域中传输时，一旦需要对报文进行重新封装，则报文中携带的随流检测信息会被剥离。即随流检测信息不能在整个检测域中传输。相应的，未接收到随流检测信息的节点则不会执行对应的随流检测操作。
其中，检测域中部署某承载协议，也可以认为是检测域中部署支持该承载协议的网络。例如，检测域部署基于互联网协议第6版分段路由(Segment Routing Internet Protocol Version 6，SRv6)协议，则表示检测域中部署SRv6网络。
为方便理解，接下来结合具体应用场景介绍上文所述的随流检测技术的局限性。随流检测技术的局限性不限于体现在下文所述的两种应用场景。相应的，本申请实施例提供的方法也不限于下文所述的两种应用场景。
参见图2，该图为本申请实施例提供的一种示例性应用场景示意图。图2示出了一种SRv6协议的业务功能链(service function chain，SFC)场景。
在图2所示的场景中，入口(ingress)运营商边缘(provider edge，PE)设备ingress PE和出口(egress)PE设备egress PE间部署SRv6网络，业务功能转发(Service Function Forwarder，SFF)设备SFF和业务功能(service function，SF)设备SF之间部署互联网协议第4版(Internet Protocol Version 4，IPv4)网络。用户网络边缘(customer edge，CE)设备CE1向用户网络边缘设备CE2发送IPv4报文，该报文在转发过程中会经过SF设备。
在一些场景中，可以将ingress PE和egress PE之间的网络指定为检测域，利用随流检测技术检测检测域的性能。接下来，对报文在检测域中的传输过程介绍随流检测技术的局限性。
步骤1、ingress PE接收到来自于CE1的IPv4报文之后，将IPv4报文重新封装成SRv6报文，并将随流检测信息封装至SRv6报文中，以指示接收到随流检测信息的节点执行随流检测操作。
在本申请实施例中，SRv6报文中可以携带业务功能链的相关信息，例如业务功能路径(service function path，SFP)，又如，业务功能链的数据。具体地，该SFC的相关信息可以携带在SFC头中，对于SRv6报文而言，该SFC头可以携带在分段路由头(segment routing header，SRH)中。
在本申请实施例中，SRv6的SRH中可以包括SID-1。SID-1为业务功能设备SF的段标识(segment identifier，SID)，即指示该SRv6报文被在转发过程中经过SF。在业务功能链场景中，该SRv6报文可以通过SFF转发给SF。SID-1还可以用于标识业务链类型。具体地，SID-1可以用于标识动态业务链或者静态业务链。
在一些实施例中，若经过该SF转发的所有业务流均使用相同的隧道转发，则SID-1用于标识静态业务链。若不是所有的业务流均使用相同的隧道转发，例如：不同业务流通过不同的隧道转发，则SID-1用于标识动态业务链。
步骤2、ingress PE将封装后的SRv6报文发送给SFF。
步骤3、SFF对接收到的SRv6报文进行重新封装，得到IPv4报文，并将IPv4报文发送给SF。
SFF对SRv6进行重新封装时，将SRv6报文中的随流检测信息剥离，换言之，SFF发送给SF的IPv4报文中不包括随流检测信息。
SFF接收到该SRv6报文之后，可以将该SRv6报文的SFC头剥离，并将该SRv6报文重新封装成IPv4报文发送给SF。
在本申请实施例中，若前述SID-1标识动态业务链，则SFF还可以将该SFC头缓存在本地，因为不同业务流对应的SFC头可能不同。若前述SID-1标识静态业务链，则SFF无需缓存该SFC，因为在这种情况下，所有业务流对应的SFC头相同，该SFC头可以通过静态配置的方式配置在SFF中。
步骤4、SF基于接收到的IPv4报文进行相应处理，处理后将该IPv4报文返回给SFF。
SF对IPv4报文进行处理，例如可以是对该IPv4报文进行安全性检测，确定该IPv4报文是否为攻击报文。
步骤5、SFF对接收到的IPv4报文重新封装成SRv6报文，并将该SRv6报文发送给egress PE，SFF发送给egress PE的SRv6报文中不包括随流检测信息。
SFF将IPv4报文重新封装成SRv6报文时，需要将SFC头封装至SRv6报文中。因此，SFF可以获取对应的SFC头。具体地，若前述SID-1标识动态业务链，则SFF在执行前述步骤3时缓存了该IPv4报文对应的SFC头，因此，SFF可以获取步骤3中缓存的SFC头，并根据该SFC头将该IPv4报文重新封装成SRv6报文。若前述SID-1标识静态业务链，则表示所有的业务报文使用相同的SFC头，对于这种情况，SFF可以获取静态配置在SFF上的SFC头，并根据获取到的SFC头将该IPv4报文重新封装成SRv6报文。
步骤6：egress PE对接收到的SRv6报文重新封装成IPv4报文发送给CE2。
在本申请实施例中，SFF发送给egress PE的SRv6报文的SRH中可以包括End.DT4 SID。该End.DT4 SID用于标识3层虚拟专用网络(layer3 virtual private network，L3VPN)，当egress PE接收到SRv6报文时，根据End.DT4 SID查找本地的私网路由，从而继续转发该报文。
通过以上描述可知，随流检测信息没有在整个检测域中传输，这是因为步骤3中SFF对接收到的SRv6报文进行重新封装时，将SRv6报文中的随流检测信息中剥离了。换言之，SFF和egress PE之间的节点均未接收到随流检测信息，因此，也就无法根据随流检测信息执行相应的检测操作。
在图2所示的场景中，SFF上运行有SF代理(proxy)，上述由SFF执行的步骤，具体可以由SF proxy执行。
需要说明的是，图2只是为了方便理解而示出，其并不构成对本申请实施例的限定。在一些实施例中，SFF和SF之间还可以部署IPv6网络、或者虚拟局域网(virtual local area network，VLAN)、或者多协议标签交换(Multi Protocol Label Switching，MPLS)网络、或者通用路由封装(generic routing encapsulation，GRE)协议网络、或者网络服务头(network service header，NSH)协议网络，本申请实施例不做具体限定。
若SFF和SF之间部署IPv6网络，则前述步骤3中，SFF需要将SRv6报文进行重新封装，得到IPv6报文；前述步骤4中，SFF接收到的报文也为IPv6报文；前述步骤5中SFF对接收到的IPv6报文重新封装成SRv6报文，并将该SRv6报文发送给egress PE。
若SFF和SF之间部署VLAN，则前述步骤3中，SFF需要将SRv6报文进行重新封装，得到采用VLAN封装的报文；前述步骤4中，SFF接收到的报文也为采用VLAN封装的报文；前述步骤5中SFF对接收到的采用VLAN封装的报文重新封装成SRv6报文，并将该SRv6报文发送给egress PE。
若SFF和SF之间部署MPLS网络，则前述步骤3中，SFF需要将SRv6报文进行重新封装，得到MPLS报文；前述步骤4中，SFF接收到的报文也为MPLS报文；前述步骤5中SFF对接收到的MPLS报文重新封装成SRv6报文，并将该SRv6报文发送给egress PE。
若SFF和SF之间部署GRE网络，则前述步骤3中，SFF需要将SRv6报文进行重新封装，得到GRE报文；前述步骤4中，SFF接收到的报文也为GRE报文；前述步骤5中SFF对接收到的GRE报文重新封装成SRv6报文，并将该SRv6报文发送给egress PE。
若SFF和SF之间部署NSH网络，则前述步骤3中，SFF需要将SRv6报文进行重新封装，得到NSH报文；前述步骤4中，SFF接收到的报文也为NSH报文；前述步骤5中SFF对接收到的NSH报文重新封装成SRv6报文，并将该SRv6报文发送给egress PE。
参见图3，该图为本申请实施例提供的又一种示例性应用场景示意图。图3为一种跨域VPN的场景示意图。
在图3所示的场景中，CE3和CE4之间进行数据交互时，要利用VPN。PE1和自治系统边界路由器(autonomous system boundary router，ASBR)ASBR1属于自治域100(即AS100)，ASBR1也是AS 100的PE设备，AS 100内部署L3VPN，AS 100部署MPLS网络或者SR-MPLS网络。PE2和ASBR2属于AS 200，ASBR2也是AS 200的PE设备，AS200内部署L3VPN，AS 200部署MPLS网络或者SR-MPLS网络。
ABSR1和ABSR2之间未部署MPLS网络，ABSR1和ABSR2之间部署IPv4网络。ASBR1将ASBR2看成与自身相连的CE设备，ASBR2也将ASBR1看成与自身相连的CE设备。ASBR1创建VPN实例之后，通过外部边界网关协议(External Border Gateway Protocol，EBGP)向ASBR2发布IPv4路由。类似的，ASBR2创建VPN实例之后，EBGP向ASBR1发布IPv4路由。
在一些场景中，可以将PE1和PE2之间的网络指定为检测域，利用随流检测技术检测检测域的性能。接下来，对报文在检测域中的传输过程介绍随流检测技术的局限性。
步骤1、CE3发送IPv4报文给PE1。
步骤2、PE1接收到来与PE1的IPv4报文之后，将IPv4报文封装成MPLS报文，并将随流检测信息封装至该MPLS报文中，以指示接收到随流检测信息的节点执行随流检测操作。
在本申请实施例中，该MPLS报文中还携带有公网标签和L3VPN的私网标签。
步骤3、PE1将该MPLS报文发送给ABSR1。
步骤4、ABSR1将接收到的MPLS报文重新封装成IPv4报文发送给ABSR2。
ABSR1对MPLS报文进行重新封装时，将MPLS报文中的随流检测信息剥离，换言之，ABSR1发送给ABSR2的IPv4报文中不包括随流检测信息。
步骤5、ASBR2接收到ASBR1发送过来的IPv4报文，对该IPv4报文重新封装，得到包括私网标签和公网标签的MPLS报文。
步骤6、ASBR2将重新封装的MPLS报文发送给PE2，ASBR2发送给PE2的MPLS报文中不包括随流检测信息。
步骤7：PE2将MPLS报文重新封装成IPv4报文发送给CE4。
通过以上描述可知，随流检测信息没有在整个检测域中传输，这是因为步骤4中ABSR1对接收到的MPLS报文进行重新封装时，将MPLS报文中的随流检测信息剥离了。换言之，AS 200中的节点均未接收到随流检测信息，因此，也就无法根据随流检测信息执行相应的检测操作。
基于以上描述可知，在实际应用中具备利用随流检测技术检测部署多个承载协议的检测域的性能的需求，而目前的随流检测技术，使得该需求不能被满足。鉴于此，本申请实施例提供了一种基于随流检测的报文处理方法，可以在检测域中部署有多种承载协议的情况下，也能利用随流检测技术进行性能检测。
以下分别结合图2和图3所示的应用场景，介绍本申请实施例提供的报文处理方法。
首先结合图2所示的应用场景，介绍本申请实施例提供的报文处理方法。
参见图4，该图为本申请实施例提供的一种基于随流检测的报文处理方法的信令交互图。图4所示的方法100，例如可以通过如下S101-S108实现。
S101：ingress PE接收到来自于CE1的报文1，报文1为IPv4报文。
在本申请实施例中，报文1为IPv4报文，即报文1是根据IPv4协议进行封装的报文。
S102：ingress PE将该报文1重新封得到报文2，报文2为SRv6报文，报文2中包括随流检测信息1。
在本申请实施例中，ingress PE作为检测域的头节点，在对报文1进行重新封装时，将随流检测信息1添加报文头中，从而得到报文2。随流检测信息1用于指示检测检测域的性能参数。检测域包括ingress PE和egress PE之间的网络。在本申请实施例中，随流检测信息1可以是iFIT随流检测信息，也可以是iOAM随流检测信息。
关于报文2的结构，可以参考下文对于图5a至图5c的描述部分，此处不做详述
S103：ingress PE将报文2发送给SFF。
S104：SFF对接收到的报文2进行重新封装，得到报文3，报文3为IPv4报文，报文3中包括随流检测信息1。
报文3是根据IPv4协议进行封装的报文。SFF将报文2重新封装得到报文3时，不是简单的将随流检测信息1从报文2中剥离，而是将从报文2中获得的随流检测信息1封装至报文3中。具体地，SFF对报文2进行重新封装时，可以将随流检测信息1添加到报文头中，以得到包括随流检测信息1的报文3。
关于报文3的结构，可以参考下文对于图6a至图6c的描述部分，此处不做详述。
S105：SFF将报文3发送给SF。
S106：SF将根据报文3得到的报文4发送给SFF，报文4中包括随流检侧信息1。
SF接收到报文3之后，对报文3进行相应的处理，而后，SF根据报文3得到报文4，并将报文4发送给SFF。具体地，SF根据报文3得到报文4在具体实现时，例如可以是SF对报文3中的源媒体接入控制(media access control，MAC)地址或者目的MAC地址等字段进行修改，从而得到报文4。在本申请实施例中，报文4是IPv4报文，并且，报文4中包括随流检测信息1。
S107：SFF根据报文4获得报文5。
SFF接收到报文4之后，根据SRv6协议对报文4进行重新封装。在对报文4进行重新封装时，将报文4中的随流检测信息1添加到按照SRv6协议进行重新封装的报文中，从而得到报文5。具体地，SFF将随流检测信息1添加到按照SRv6协议进行重新封装的报文头中，从而重新获得报文5。
S108：SFF将报文5发送给egress PE。
由于报文5中包括随流检测信息1，因此，egress PE以及egress PE与SFF之间的节点均可以接收到包括随流检测信息1的报文5。
通过以上描述可知，随流检测信息1可以在整个检测域中传输，因此，接收到该随流检测信息1的节点均可以执行随流检测操作，从而使得在检测域中部署有SRv6协议和IPv4协议这两种承载协议的情况下，也可以利用随流检测技术对检测域进行性能检测。
对于该方法100，在一些实施例中，图2所示的检测域可以包括域A和域B，其中，域A中部署的承载协议为SRv6协议，域B中部署的承载协议为IPv4协议。域A中包括ingress PE和SFF，或者域A包括egress PE和SFF，域B中包括SFF和SF。
参见图5a，图5a示出了一种可能的SRv6报文的结构示意图。
图5a示出的SRv6报文，包括ETH字段、IPv6 Basic Header、SRH和Payload。
其中：
ETH字段用于携带二层以太头，ETH中可以携带源MAC地址、目的MAC地址和协议类型。
IPv6 Basic Header为IPv6基本头，其具体包含的字段此处不做详细说明。
SRH字段包括SRH Basic Header、Segment List以及Option类型长度值(type length value，TLV)。具体地：SRH Basic Header为SRH基本扩展头，其具体包含的字段此处不做详细说明。Segment List用于携带指示报文转发路径的段标识列表。Option TLV可以作为扩展字段。在本申请实施例中，前述随流检测信息1可以携带在Option TLV中。
参见图5b，图5b示出了当随流检测信息1为iFIT随流检测信息时，SRv6报文的结构。
在图5b中，流指令指示符(flow instruction indicator，FII)字段、流指令头部(flow instruction header，FIH)字段、以及流指令扩展头(flow instruction extension header，FIEH)字段构成iFIT信息。以下分别对FII字段、FIH字段以及FIEH字段进行简单说明。
1、FII字段主要用于标识该字段后的若干字节数据为IFIT信息。FII字段例如可以包括以下字段信息：
Type字段，用于标识iFIT检测头；
Length字段，用于标识FIH字段和FIEH字段的长度；
Reserved字段为预留字段。
2、FIH字段也可以称之为随流检测头或流检测头。该字段主要用于携带IFIT检测相关的信息。例如可以包括以下字段信息：
流标识(英文：Flow ID)，为每条IFIT检测流量分配的全局唯一标识；
L标志位，丢包(英文：packet loss)检测染色标记，例如：L标志位取值为“1”表示采集丢包，“0”表示不采集丢包。
D标志位，时延(英文：delay)测量染色标记，例如：D标志位取值为“1”表示采集时间戳，“0”表示不采集时间戳。
头类型指示符(header type indicator，HTI)，标记需发送IFIT检测结果的节点范围和检测内容范围，例如：可以用不同的标记值区分除检测两端节点外，是否对具备iFIT能力的路径节点进行检测，以及FIEH字段是否有效等。
R标志位可以作为保留标志位。
3、FIEH字段也可以称之为流扩展检测头或者扩展随流检测头。该字段作为扩展字段，主要用于携带其他iFIT检测相关的信息。例如可以包括以下字段信息：
流标识扩展Flow ID Ext，用于扩展流标识位宽；
V标志位，用于作反向流(英文：reverse flow)标记，例如：V标志位取值为“0”表示当前流为正向流，接收端可自动创建反向流；“1”表示当前流为反向流，接收端不再自动创建反向流，其中，V标志位为可选字段，图1中并未示出；
周期(英文：Period)，取值不同表示检测周期不同，检测周期例如可以为1s、10s、30s、1min或10min等。
参见图5c，图5c示出了当随流检测信息1为iOAM随流检测信息时，SRv6报文的结构。
如图5c所示，iOAM随流检测信息包括SRH-TLV-Type字段、iOAM-Type字段、iOAM HDR LEN字段、iOAM Option and Data Space字段以及RESERVED字段。
其中：
SRH-TLV-Type字段用于标识iOAM封装，即用于标识该字段后的若干字节数据为iOAM信息。
iOAM-Type字段用于指示iOAM类型。
iOAM HDR LEN字段用于标识iOAM头的长度。
iOAM Option and Data Space字段为iOAM选项和数据字段，用于携带指示节点执行相应随流检测操作的指示信息。
RESERVED字段为保留字段。
参见图6a，图6a示出了一种可能的IPv4报文的结构示意图。
在图6a中，IPv4报文包括ETH字段，IPv4 Header和Payload。随流检测信息1可以位于IPv4 Header中。在一个示例中，随流检测信息1可以位于IPv4 Header的选项(options)字段中。其中：
ETH字段用于携带二层以太头，ETH中可以携带源媒体接入控制(media access control，MAC)地址，目的MAC地址和协议类型。
IPv4 Header中的各个字段，此处不做详细说明。
在本申请实施例中，图6a所示的随流检测信息1可以是iFIT随流检测信息，也可以是iOAM随流检测信息。
iFIT随流检测信息可以参考图5b对于iFIT随流检测信息的描述部分，此处不做详述。
当随流检测信息1是iOAM随流检测信息时，可参考图6b进行理解，图6b示出了当随流检测信息1为iOAM随流检测信息时，IPv4报文的结构。
如图6b所示，iOAM随流检测信息可以位于IPv4 Header的options字段中。具体地：iOAM随流检测信息包括Option Type字段、Option Length字段、RESERVED字段、iOAM-Type字段以及Option Data字段。其中：
Option Type字段用于指示iOAM封装类型的选项头。
Option Length字段用于指示整个iOAM头的长度。
RESERVED为保留字段。
iOAM-Type字段用于指示iOAM类型。
Option Data字段为iOAM选项和数据字段，用于携带指示节点执行相应随流检测操作的指示信息。
参见图6c，图6c示出了又一种可能的IPv4报文的结构示意图。
在图6c中，IPv4报文包括ETH字段、IPv4 Header、传输控制协议(Transmission Control Protocol，TCP)/用户数据报协议(User Datagram Protocol，UDP)、魔术数字(probe mark)字段、随流检测头和Payload。
关于ETH、IPv4 Header、TCP/UDP，此处不做详细说明。
魔术数字字段用于指示接下来的若干个字节数据为随流检测数据，魔术数字字段例如可以包括8字节。
当随流检测信息1为iFIT随流检测信息时，魔术数字字段例如可以对应图5b所示的FII字段，随流检测头例如可以包括图5b所示的FIH字段和FIEH字段。关于FII字段、FIH字段和FIEH字段，可以参考上文对于图5b的描述部分，此处不再详述。
当随流检测信息1为iOAM随流检测信息时，魔术数字字段以及随流检测头的具体封装形式本申请实施例不做具体限定，作为一种示例：魔术数字字段例如可以对应图5c所示的SRH-TLV-Type字段，随流检测头例如可以包括图5c所示的iOAM-Type字段、iOAM HDR LEN字段、iOAM Option and Data Space字段以及RESERVED字段。
接下来结合图3所示的应用场景，介绍本申请实施例提供的报文处理方法。
参见图7，该图为本申请实施例提供的一种基于随流检测的报文处理方法的信令交互图。图7所示的方法200，例如可以通过如下S201-S207实现。
S201：PE1接收来自于CE3的报文6，报文6为IPv4报文。
S202：PE1将报文6重新封装成报文7，报文7为MPLS报文，报文7中包括随流检测信息2。
在本申请实施例中，报文7中包括公网标签和L3VPN的私网标签。
在本申请实施例中，检测域包括PE1和PE2之间的网络。PE1作为检测域的头节点，在对报文6进行重新封装时，将随流检测信息2添加到报文头中，从而得到报文7。随流检测信息2可以是iFIT随流检测信息，也可以是iOAM随流检测信息。
关于报文7的结构，可以参考下文对于图8a至图8b的描述部分，此处不做详述。
S203：PE1将报文7发送给ABSR1。
S204：ABSR1对接收到的报文7进行重新封装，得到报文8，报文8为IPv4报文，报文8中包括随流检测信息2。
报文8是根据IPv4协议进行封装的报文。ABSR1将报文7重新封装得到报文8时，不是简单的将随流检测信息2从报文7中剥离，而是将从报文7中获得的随流检测信息2封装至报文8中。具体地，ABSR1对报文7进行重新封装时，可以将随流检测信息2添加到报文头中，以得到包括随流检测信息2的报文8。
关于报文8的结构，可以参考上文对于图6a至图6c的描述部分，此处不做详述。
S205：ABSR1将报文8发送给ABSR2。
S206：ABSR2对接收到的报文8进行重新封装，得到报文9，报文9为MPLS报文，报文9中包括随流检测信息2。
报文9是根据MPLS协议进行封装的报文。ABSR2将报文8重新封装得到报文9时，不是简单的将随流检测信息2从报文8中剥离，而是将从报文8中获得的随流检测信息2封装至报文9中。具体地，ABSR2对报文8进行重新封装时，可以将随流检测信息2添加到报文头中，以得到包括随流检测信息2的报文9。
报文9的结构与报文7的结构相同，可以参考下文对于图8a和图8b的描述部分。
S207：ABSR2将报文9发送给PE2。
由于前述报文7、报文8以及报文9中均携带随流检测信息2，因此，随流检测信息2可以在整个检测域中传输。因此，接收到该随流检测信息2的节点均可以执行随流检测操作，从而使得在检测域中部署有MPLS协议和IPv4协议这两种承载协议的情况下，也可以利用随流检测技术对检测域进行性能检测。
需要说明的是，在图3所示的应用场景中，
对于该方法200，在一些实施例中，图3所示的网络域可以包括域C、域D和域E，其中，域C中部署的承载协议为MPLS协议，域D中部署的承载协议为IPv4协议,域E中部署的承载协议为MPLS协议。域C中包括PE1和ABSR1，域D中包括ABSR1和ABSR2，域E中包括ABSR2和PE2。
参见图8a，图8a示出了一种可能的MPLS报文的结构示意图。
图8a示出的MPLS报文，包括ETH字段、SR Label字段、VPN Label字段、随流检测头和Payload。其中：
ETH字段用于携带二层以太头，ETH中可以携带源MAC地址、目的MAC地址和协议类型。
SR Label用于携带公网标签。
VPN Label用于携带私网标签。
随流检测头可以用于携带图8b所示的iFIT随流检测信息，也可以用于携带图8c所示的iOAM随流检测信息。
图8b所示的iFIT随流检测信息包括：FII字段、FIH字段和FIEH字段。
其中：
FII字段主要用于标识该字段后的若干字节数据为IFIT信息。FII字段例如可以包括以下字段信息：
流指令指示符标签(英文：FII Label)，可配置缺省值以用于标识iFIT检测流；
优先级EXP标志位，该优先级EXP标志位可以根据外层MPLS标签头中的部分相关信息确定；
S标志位，用于标记是否为栈底，例如取值为1为栈底，取值为0为非栈底；
生存时间(time to live，TTL)标志位，该TTL标志位也可以根据外层MPLS标签头中的部分相关信息确定。
关于FIH字段和FIEH字段，可以参考上文对图5b的说明部分，此处不再重复描述。
图8c所示的iOAM随流检测信息，包括：iOAM指示标签(Indicator Label)字段、iOAM-Type字段、iOAM HDR LEN字段、IOAM Option and Data Space字段、以及RESERVED字段。其中：
iOAM Indicator Label字段用于标识iOAM封装，即用于标识该字段后的若干字节数据为iOAM信息。
iOAM-Type字段用于指示iOAM类型。
iOAM HDR LEN字段用于标识iOAM头的长度。
iOAM Option and Data Space字段为iOAM选项和数据字段，用于携带指示节点执行相应随流检测操作的指示信息。
RESERVED字段为保留字段。
本申请实施例还提供了一种基于随流检测的报文处理方法300，可参见图9，图9为本申请实施例提供的一种基于随流检测的报文处理方法的流程示意图。以下结合图9对该方法进行说明。图9所示的方法300，例如可以通过S301-S302实现。
S301：第一节点接收来自于第二节点的第一报文，所述第一报文的第一报文头中包括第一随流检测信息，所述第一报文为采用第一承载协议进行封装的报文。
S302：所述第一节点根据所述第一报文得到第二报文，所述第二报文的第二报文头中包括所述第一随流检测信息，所述第二报文为采用第二承载协议进行封装的报文，所述第一承载协议与所述第一第二承载协议为不同的承载协议。
S303：所述第一节点将所述第二报文转发给第三节点。
方法300可以用于实现以上实施例提及的方法100中SFF执行的步骤，方法300还可以用于执行以上实施例提及的方法200中由ABSR1或者ABSR2执行的步骤。
在一些实施例中，当方法300可以用于实现以上实施例提及的方法100中SFF执行的步骤时，第一节点对应图2所示的SFF，第二节点对应于图2所示的ingress PE，第一报文对应方法100中的报文2，第一承载协议为SRv6协议，第一随流检测信息为方法100中的随流检测信息1。第二报文对应方法100中的报文3，第二承载协议为IPv4协议。第三节点为方法100中的SF。
在一些实施例中，当方法300可以用于实现以上实施例提及的方法100中SFF执行的步骤时，第一节点对应图2所示的SFF，第二节点对应图2所述的SF，第一报文对应方法100中的报文4，第一承载协议为IPv4协议，第一随流检测信息为方法100中的随流检测信息1。第二报文对应方法100中的报文5，第二承载协议为SRv6协议，第三节点对应图2所示的egress PE。
当方法300用于实现以上实施例提及的方法200中ABSR1执行的步骤时，第一节点对应图3所示的ABSR1，第二节点对应于图3所示的PE1，第一报文对应方法200中的报文7，第一承载协议为MPLS协议，第一随流检测信息为方法200中的随流检测信息2。第二报文对应方法200中的报文8，第二承载协议为IPv4协议。第三节点为方法200中的ABSR2。
当方法300用于实现以上实施例提及的方法200中ABSR2执行的步骤时，第一节点对应图3所示的ABSR2，第二节点对应于图3所示的ABSR1，第一报文对应方法200中的报文8，第一承载协议为IPv4协议，第一随流检测信息为方法200中的随流检测信息2。第二报文对应方法200中的报文9，第二承载协议为MPLS协议。第三节点为方法200中的PE2。
在一种实现方式中，所述第一承载协议为IPv4协议、IPv6协议、MPLS协议、VLAN协议、GRE协议、NSH协议或者SRv6协议；所述第二承载协议为IPv4协议、IPv6协议、MPLS协议、VLAN协议、GRE协议、NSH协议或者SRv6协议。
在一种实现方式中，所述第一随流检测信息用于指示检测检测域的性能参数，所述检测域包括第一域和第二域，所述第二节点属于所述第一域，所述第三节点属于所述第二域，所述第一节点为所述第一域和所述第二域的跨域节点。
当方法300可以用于实现以上实施例提及的方法100中SFF执行的步骤时，检测域为图2所示的检测域，第一域可以包括ingress PE和SFF，即对应前文提及的域A，第二域可以包括SFF和SF，即对应前文提及的域B。第一节点对应图2所示的SFF，第二节点对应图2所示的ingress PE，第三节点对应图2所示的SF。对于这种情况，在一些实施例中，第一节点还可以用于接收所述第三节点返回的第三报文，所述第三报文包括所述第一随流检测信息，所述第三报文为采用所述第二承载协议进行封装的报文；所述第一节点根据所述第三报文，生成第四报文，所述第四报文包括所述第一随流检测信息，所述第四报文为采用所述第一承载协议进行封装的报文；所述第一节点向下一跳节点发送所述第一报文。此处提及的第三报文对应方法100中的报文4，第一随流检测信息对应方法100中的随流检测信息1，第四报文对应方法100中的报文5。第一承载协议为IPv4协议，第二承载协 议为SRv6协议。
在一种实现方式中，所述第一域部署SRv6网络，所述第二域部署IPv4网络，所述第一报文为携带SFC信息的SRv6报文，所述第二报文为携带所述SFC信息的IPv4报文。其中，第一域包括图2所示的ingress PE和SFF，即第一域对应前文提及的域A，第二域包括图2所示的SFF和SF，即第二域对应前文提及的域B。
在一种实现方式中，所述第一域部署IPv4网络，所述第二域部署SRv6网络，所述第一报文为携带SFC信息的IPv4报文，所述第二报文为携带SFC信息的SRv6报文。其中，第一域包括图2所示的SFF和SF，即第一域对应前文提及的域B，第二域包括图2所示的SFF和egress PE，即第二域对应前文提及的域A。
在一种实现方式中，当方法300可以用于实现以上实施例提及的方法200中ABSR1执行的步骤时，所述检测域为图3所示的检测域。所述第一域部署MPLS网络，所述第二域部署IPv4网络，所述第一报文为MPLS报文，所述第二报文为IPv4报文。其中，第一域可以包括图3所示的PE1和ABSR1，即第一域可以对应前文提及的域C，第二域可以包括图3所示的ABSR1和ABSR2，即第二域可以包括前文提及的域D。此时，第一报文可以对应方法200中的报文7，第二报文可以对应方法200中的报文8。
在一种实现方式中，所述第一域部署三层虚拟专用网络L3VPN。
在一种实现方式中，所述检测域还包括第三域，所述第三域部署MPLS网络，所述第三节点为所述第二域和所述第三域的跨域节点。其中，第三域可以包括图3所示的ABSR2和PE2，即第三域可以对应前文提及的域E，此时，第三节点为ABSR2。
在一种实现方式中，所述第三域部署L3VPN。
在一种实现方式中，所述第一域为第一自治系统，所述第一节点为所述第一自治系统的ABSR；所述第三域为第二自治系统，所述第三节点为所述第二自治系统的ABSR。即前文提及的域C和域D均为自治系统，第一节点对应图3所示的ASBR1，第三节点对应图3所示的ASBR2。
在一种实现方式中，当方法300可以用于实现以上实施例提及的方法200中ABSR2执行的步骤时，所述第一域部署IPv4网络，所述第二域部署MPLS网络，所述第一报文为IPv4报文，所述第二报文为MPLS报文。对于这种情况，第一域可以包括图3所示的ABSR1和ABSR2，即第一域对应前文提及的域D，第二域可以包括图3所示的ABSR2和PE2，即第二域可以对应前文提及的域E。此时，第一节点可以对应方法200中的ABSR2，第一报文可以对应方法200中的报文8，第二报文可以对应方法200中的报文9。
在一种实现方式中，所述第二域部署L3VPN。
在一种实现方式中，所述第一随流检测信息包括：iFIT随流检测信息，或者，iOAM随流检测信息。
关于方法300的具体实现，可以参考以上实施例中关于方法100和方法200的相关描述部分，此处不再详述。
此外，本申请实施例还提供了一种第一节点1000，参见图10所示，图10为本申请实施例提供的一种第一节点的结构示意图。该第一节点1000包括收发单元1001和处理单元 1002。其中，收发单元1001用于执行上述方法100对应的实施例中由SFF执行的收发操作；处理单元1002用于执行上述方法100对应的实施例中由SFF执行的除了收发操作以外的其他操作。或者，收发单元1001用于执行上述方法200对应的实施例中由ABSR1执行的收发操作；处理单元1002用于执行上述方法200对应的实施例中由ABSR1执行的除了收发操作以外的其他操作。或者，收发单元1001用于执行上述方法200对应的实施例中由ABSR2执行的收发操作；处理单元1002用于执行上述方法200对应的实施例中由ABSR2执行的除了收发操作以外的其他操作。例如：第一节点1000为方法100中的SFF，那么，收发单元1001用于执行接收来自于ingress PE的报文2的步骤、以及用于执行向SF发送报文3的步骤；所述处理单元1002用于执行根据报文2获得报文3的步骤。
此外，本申请实施例还提供了一种第一节点1100，参见图11所示，图11为本申请实施例提供的一种第一节点的结构示意图。该第一节点1100包括通信接口1101和与通信接口1101连接的处理器1102。其中，通信接口1101用于执行上述方法100对应的实施例中由SFF执行的收发操作；处理器1102用于执行上述方法100对应的实施例中由SFF执行的除了收发操作以外的其他操作。或者，通信接口1101用于执行上述方法200对应的实施例中由ABSR1执行的收发操作；处理器1102用于执行上述方法200对应的实施例中由ABSR1执行的除了收发操作以外的其他操作。或者，通信接口1101用于执行上述方法200对应的实施例中由ABSR2执行的收发操作；处理器1102用于执行上述方法200对应的实施例中由ABSR2执行的除了收发操作以外的其他操作。例如：第一节点1100为方法100中的SFF，那么，通信接口1101用于执行接收来自于ingress PE的报文2的步骤、以及用于执行向SF发送报文3的步骤；所述处理器1102用于执行根据报文2获得报文3的步骤。
此外，本申请实施例还提供了一种第一节点1200，参见图12所示，图12为本申请实施例提供的一种第一节点的结构示意图。该第一节点1200包括存储器1201和处理器1202。其中，存储器1201用于存储程序代码；处理器1202用于运行所述程序代码中的指令，使得该第一节点1200执行上述方法100对应的实施例中SFF执行的步骤，或者，使得该第一节点1200执行上述方法200对应的实施例中ABSR1执行的步骤，或者，使得该第一节点1200执行上述方法200对应的实施例中ABSR2执行的步骤。
此外，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得所述计算机执行上述方法100对应的实施例中SFF执行的步骤，或者，使得所述计算机执行上述方法200对应的实施例中ABSR1执行的步骤，或者，使得所述计算机执行上述方法200对应的实施例中ABSR2执行的步骤。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑业务划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各业务单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件业务单元的形式实现。
集成的单元如果以软件业务单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的业务可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些业务存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。
以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已。
以上，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (34)

  1. 一种基于随流检测的报文处理方法，其特征在于，包括：
    第一节点接收来自于第二节点的第一报文，所述第一报文的第一报文头中包括第一随流检测信息，所述第一报文为采用第一承载协议进行封装的报文；
    所述第一节点根据所述第一报文得到第二报文，所述第二报文的第二报文头中包括所述第一随流检测信息，所述第二报文为采用第二承载协议进行封装的报文，所述第一承载协议与所述第一第二承载协议为不同的承载协议；
    所述第一节点将所述第二报文转发给第三节点。
  2. 根据权利要求1所述的方法，其特征在于，
    所述第一承载协议为互联网协议第4版IPv4协议、互联网协议第6版IPv6协议、多协议标签交换MPLS协议、虚拟局域网VLAN协议、通用路由封装GRE协议、网络服务头NSH协议或者互联网协议第6版分段路由SRv6协议；
    所述第二承载协议为IPv4协议、IPv6协议、MPLS协议、VLAN协议、GRE协议、NSH协议或者SRv6协议。
  3. 根据权利要求1或2所述的方法，其特征在于，
    所述第一随流检测信息用于指示检测检测域的性能参数，所述检测域包括第一域和第二域，所述第二节点属于所述第一域，所述第三节点属于所述第二域，所述第一节点为所述第一域和所述第二域的跨域节点。
  4. 根据权利要求1-3任一项所述的方法，其特征在于，所述第一节点为业务功能代理SF proxy，所述第三节点为业务功能SF设备。
  5. 根据权利要求4所述的方法，其特征在于，所述方法还包括：
    所述第一节点接收所述第三节点返回的第三报文，所述第三报文包括所述第一随流检测信息，所述第三报文为采用所述第二承载协议进行封装的报文；
    所述第一节点根据所述第三报文，生成第四报文，所述第四报文包括所述第一随流检测信息，所述第四报文为采用所述第一承载协议进行封装的报文；
    所述第一节点向下一跳节点发送所述第一报文。
  6. 根据权利要求3-5任意一项所述的方法，其特征在于，所述第一域部署SRv6网络，所述第二域部署IPv4网络，所述第一报文为SRv6报文，所述第二报文为IPv4报文。
  7. 根据权利要求3或4所述的方法，其特征在于，所述第一域部署IPv4网络，所述第二域部署SRv6网络，所述第一报文为IPv4报文，所述第二报文为SRv6报文。
  8. 根据权利要求3所述的方法，其特征在于，所述第一域部署MPLS网络，所述第二域部署IPv4网络，所述第一报文为MPLS报文，所述第二报文为IPv4报文。
  9. 根据权利要求8所述的方法，其特征在于，所述第一域用于承载三层虚拟专用网络L3VPN业务。
  10. 根据权利要求8或9所述的方法，其特征在于，所述检测域还包括第三域，所述第三域部署MPLS网络，所述第三节点为所述第二域和所述第三域的跨域节点。
  11. 根据权利要求10所述的方法，其特征在于，所述第三域用于承载L3VPN业务。
  12. 根据权利要求10或11所述的方法，其特征在于，
    所述第一域为第一自治系统AS，所述第一节点为所述第一AS的自治系统边界路由器ABSR；
    所述第三域为第二AS，所述第三节点为所述第二AS的ABSR。
  13. 根据权利要求3所述的方法，其特征在于，所述第一域部署IPv4网络，所述第二域部署MPLS网络，所述第一报文为IPv4报文，所述第二报文为MPLS报文。
  14. 根据权利要求13所述的方法，其特征在于，所述第二域用于承载L3VPN业务。
  15. 根据权利要求1-14任意一项所述的方法，其特征在于，所述第一随流检测信息包括：
    随流信息遥测iFIT随流检测信息，或者，带内操作管理维护iOAM随流检测信息。
  16. 一种第一节点，其特征在于，包括：
    通信接口；和
    与所述通信接口连接的处理器；
    根据所述通信接口和所述处理器，所述第一节点用于执行前述权利要求1-15任一项所述的方法。
  17. 一种第一节点，其特征在于，所述第一节点包括存储器和处理器；
    所述存储器，用于存储程序代码；
    所述处理器，用于运行所述程序代码中的指令，使得所述第一节点执行以上权利要求1-15任一项所述的方法。
  18. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得所述计算机执行以上权利要求1-15任意一项所述的方法。
  19. 一种基于随流检测的报文处理装置，其特征在于，应用于第一节点，所述装置包括：
    接收单元，用于接收来自于第二节点的第一报文，所述第一报文的第一报文头中包括第一随流检测信息，所述第一报文为采用第一承载协议进行封装的报文；
    处理单元，用于根据所述第一报文得到第二报文，所述第二报文的第二报文头中包括所述第一随流检测信息，所述第二报文为采用第二承载协议进行封装的报文，所述第一承载协议与所述第一第二承载协议为不同的承载协议；
    发送单元，用于将所述第二报文转发给第三节点。
  20. 根据权利要求19所述的装置，其特征在于，
    所述第一承载协议为互联网协议第4版IPv4协议、互联网协议第6版IPv6协议、多协议标签交换MPLS协议、虚拟局域网VLAN协议、通用路由封装GRE协议、网络服务头NSH协议或者互联网协议第6版分段路由SRv6协议；
    所述第二承载协议为IPv4协议、IPv6协议、MPLS协议、VLAN协议、GRE协议、NSH协议或者SRv6协议。
  21. 根据权利要求19或20所述的装置，其特征在于，
    所述第一随流检测信息用于指示检测检测域的性能参数，所述检测域包括第一域和第二域，所述第二节点属于所述第一域，所述第三节点属于所述第二域，所述第一节点为所述第一域和所述第二域的跨域节点。
  22. 根据权利要求19-21任一项所述的装置，其特征在于，所述第一节点为业务功能代理SF proxy，所述第三节点为业务功能SF设备。
  23. 根据权利要求22所述的装置，其特征在于，
    所述接收单元，还用于接收所述第三节点返回的第三报文，所述第三报文包括所述第一随流检测信息，所述第三报文为采用所述第二承载协议进行封装的报文；
    所述处理单元，还用于根据所述第三报文，生成第四报文，所述第四报文包括所述第一随流检测信息，所述第四报文为采用所述第一承载协议进行封装的报文；
    所述发送单元，还用于向下一跳节点发送所述第一报文。
  24. 根据权利要求21-23任意一项所述的装置，其特征在于，所述第一域部署SRv6网络，所述第二域部署IPv4网络，所述第一报文为SRv6报文，所述第二报文为IPv4报文。
  25. 根据权利要求21或22所述的装置，其特征在于，所述第一域部署IPv4网络，所述第二域部署SRv6网络，所述第一报文为IPv4报文，所述第二报文为SRv6报文。
  26. 根据权利要求25所述的装置，其特征在于，所述第一域部署MPLS网络，所述第二域部署IPv4网络，所述第一报文为MPLS报文，所述第二报文为IPv4报文。
  27. 根据权利要求26所述的装置，其特征在于，所述第一域用于承载三层虚拟专用网络L3VPN业务。
  28. 根据权利要求26或27所述的装置，其特征在于，所述检测域还包括第三域，所述第三域部署MPLS网络，所述第三节点为所述第二域和所述第三域的跨域节点。
  29. 根据权利要求28所述的装置，其特征在于，所述第三域用于承载L3VPN业务。
  30. 根据权利要求28或29所述的装置，其特征在于，
    所述第一域为第一自治系统AS，所述第一节点为所述第一AS的自治系统边界路由器ABSR；
    所述第三域为第二AS，所述第三节点为所述第二AS的ABSR。
  31. 根据权利要求21所述的装置，其特征在于，所述第一域部署IPv4网络，所述第二域部署MPLS网络，所述第一报文为IPv4报文，所述第二报文为MPLS报文。
  32. 根据权利要求31所述的装置，其特征在于，所述第二域用于承载L3VPN业务。
  33. 根据权利要求19-32任意一项所述的装置，其特征在于，所述第一随流检测信息包括：
    随流信息遥测iFIT随流检测信息，或者，带内操作管理维护iOAM随流检测信息。
  34. 一种计算机程序产品，包括计算机程序，其特征在于，当所述计算机程序在处理器上运行时，实现权利要求1-15任意一项所述的方法。
PCT/CN2021/079921 2020-04-24 2021-03-10 一种基于随流检测的报文处理方法及装置 WO2021213045A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP21793650.9A EP4131855A4 (en) 2020-04-24 2021-03-10 PACKET PROCESSING METHOD AND APPARATUS BASED ON IN-SITU FLOW DETECTION
JP2022564126A JP2023522736A (ja) 2020-04-24 2021-03-10 現地フロー検出ベースのパケット処理方法及び装置
US17/971,327 US20230045227A1 (en) 2020-04-24 2022-10-21 In-situ flow detection-based packet processing method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010332211.0A CN113556259B (zh) 2020-04-24 2020-04-24 一种基于随流检测的报文处理方法及装置
CN202010332211.0 2020-04-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/971,327 Continuation US20230045227A1 (en) 2020-04-24 2022-10-21 In-situ flow detection-based packet processing method and apparatus

Publications (1)

Publication Number Publication Date
WO2021213045A1 true WO2021213045A1 (zh) 2021-10-28

Family

ID=78129657

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/079921 WO2021213045A1 (zh) 2020-04-24 2021-03-10 一种基于随流检测的报文处理方法及装置

Country Status (5)

Country Link
US (1) US20230045227A1 (zh)
EP (1) EP4131855A4 (zh)
JP (1) JP2023522736A (zh)
CN (1) CN113556259B (zh)
WO (1) WO2021213045A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230231804A1 (en) * 2021-03-25 2023-07-20 New H3C Technologies Co., Ltd. In-situ flow detection method and electronic device
CN115134273A (zh) * 2021-03-29 2022-09-30 北京华为数字技术有限公司 一种报文处理方法以及相关设备
CN114205267A (zh) * 2021-12-15 2022-03-18 中国电信股份有限公司 链路信息的追踪方法、系统和服务功能
WO2023179457A1 (zh) * 2022-03-21 2023-09-28 华为技术有限公司 业务连接的标识方法、装置、系统及存储介质
CN114745302B (zh) * 2022-03-30 2023-09-15 新华三技术有限公司 通信方法及装置
CN115174449B (zh) * 2022-05-30 2024-03-26 杭州初灵信息技术股份有限公司 一种传递随流检测信息的方法、系统、装置和存储介质
CN117749670A (zh) * 2022-09-15 2024-03-22 中兴通讯股份有限公司 随流检测的方法、封装节点、检测节点、计算机可读介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108737269A (zh) * 2017-04-13 2018-11-02 中兴通讯股份有限公司 一种封装方法、装置和节点
US20180331933A1 (en) * 2017-05-12 2018-11-15 Futurewei Technologies, Inc. In-situ oam sampling and data validation
CN109743340A (zh) * 2019-04-04 2019-05-10 华为技术有限公司 报文处理的方法和网络装置
US20200084143A1 (en) * 2018-09-11 2020-03-12 Cisco Technology, Inc. In-situ operation, administration, and maintenance in segment routing with multiprotocol label switching networks

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9008081B2 (en) * 2006-12-14 2015-04-14 Rpx Clearinghouse Llc Serving gateway proxies for non-SIP speakers in a next generation network
US8665724B2 (en) * 2009-06-12 2014-03-04 Cygnus Broadband, Inc. Systems and methods for prioritizing and scheduling packets in a communication network
KR20140053346A (ko) * 2011-08-18 2014-05-07 브이아이디 스케일, 인크. 패킷 차등화를 위한 방법 및 시스템
CN107276840A (zh) * 2016-04-07 2017-10-20 华为技术有限公司 一种监控数据传输的方法及相关设备
CN107579869B (zh) * 2016-07-04 2020-09-08 华为技术有限公司 网络性能检测方法和网络设备
US10693777B2 (en) * 2018-06-26 2020-06-23 Cisco Technology, Inc. In-situ operations, administration, and maintenance (iOAM) for software defined architectures (SDAs)
CN110381119B (zh) * 2019-06-20 2022-05-17 视联动力信息技术股份有限公司 一种日志信息的获取方法、系统及装置和存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108737269A (zh) * 2017-04-13 2018-11-02 中兴通讯股份有限公司 一种封装方法、装置和节点
US20180331933A1 (en) * 2017-05-12 2018-11-15 Futurewei Technologies, Inc. In-situ oam sampling and data validation
US20200084143A1 (en) * 2018-09-11 2020-03-12 Cisco Technology, Inc. In-situ operation, administration, and maintenance in segment routing with multiprotocol label switching networks
CN109743340A (zh) * 2019-04-04 2019-05-10 华为技术有限公司 报文处理的方法和网络装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4131855A4

Also Published As

Publication number Publication date
EP4131855A4 (en) 2023-09-13
CN113556259B (zh) 2024-04-12
EP4131855A1 (en) 2023-02-08
JP2023522736A (ja) 2023-05-31
CN113556259A (zh) 2021-10-26
US20230045227A1 (en) 2023-02-09

Similar Documents

Publication Publication Date Title
WO2021213045A1 (zh) 一种基于随流检测的报文处理方法及装置
US11848757B2 (en) In-situ passive performance measurement in a network environment
US11438254B2 (en) Apparatus and method to trace packets in a packet processing pipeline of a software defined networking switch
WO2021170092A1 (zh) 报文处理方法、装置、网络设备及存储介质
CN113079091B (zh) 一种主动随流检测的方法、网络设备以及通信系统
CN111953604B (zh) 一种为业务流提供业务服务的方法和装置
EP3832957A1 (en) Transmission control method, node, network system, and storage medium
EP3713162A1 (en) Route processing method and apparatus, and data transmission method and apparatus
US10630575B2 (en) Mechanism to detect control plane loops in a software defined networking (SDN) network
CN106464590B (zh) 一种获取路径信息的方法及装置
US20230006906A1 (en) In-situ flow detection method and apparatus
CN105245452B (zh) 多协议标签交换流量工程隧道建立方法及设备
US10833975B2 (en) Operations processing of multiple-protocol packets by packet switching devices in a network
CN111669422B (zh) 报文的传输方法和设备
US20130259057A1 (en) Pseudowire groups in a packet switched network
US11082540B2 (en) Network operations including protocol processing of a packet updating an operations data field of a different protocol
WO2016119461A1 (zh) 一种建立bgp lsp隧道的方法及网络设备
Kushwaha et al. Bitstream: A flexible SDN protocol for service provider networks
CN115225427B (zh) 一种传输数据报文的方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21793650

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022564126

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021793650

Country of ref document: EP

Effective date: 20221027

NENP Non-entry into the national phase

Ref country code: DE