WO2022198560A1 - 随流检测方法和电子设备 - Google Patents

随流检测方法和电子设备 Download PDF

Info

Publication number
WO2022198560A1
WO2022198560A1 PCT/CN2021/082981 CN2021082981W WO2022198560A1 WO 2022198560 A1 WO2022198560 A1 WO 2022198560A1 CN 2021082981 W CN2021082981 W CN 2021082981W WO 2022198560 A1 WO2022198560 A1 WO 2022198560A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
detection
flow
option
field
Prior art date
Application number
PCT/CN2021/082981
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 US18/001,865 priority Critical patent/US20230231804A1/en
Priority to JP2022579791A priority patent/JP7446489B2/ja
Priority to EP21932187.4A priority patent/EP4152658A4/en
Priority to PCT/CN2021/082981 priority patent/WO2022198560A1/zh
Priority to CN202180000608.2A priority patent/CN115280745B/zh
Priority to KR1020227042506A priority patent/KR20230005369A/ko
Publication of WO2022198560A1 publication Critical patent/WO2022198560A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • 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/56—Routing software
    • H04L45/566—Routing instructions carried by the data packet, e.g. active networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/12—Arrangements for remote connection or disconnection of substations or of equipment thereof
    • 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
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • 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
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • 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/24—Multipath
    • 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/38—Flow based 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/74—Address processing for routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2483—Traffic characterised by specific attributes, e.g. priority or QoS involving identification of individual flows
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/659—Internet protocol version 6 [IPv6] addresses

Definitions

  • the present application relates to the technical field of network communication, and in particular, to a flow detection method and an electronic device.
  • On-stream detection refers to network detection using normally forwarded service packets.
  • Flow detection can be accomplished by the cooperation of network devices and analyzers, which can be implemented in the following ways:
  • the network device serving as an ingress (Ingress) inserts detection control information into the service packet, collects data based on the detection control information inserted in the service packet, and reports the collected data to the analyzer.
  • a network device serving as a transit node (Transmit) or an egress node (Egress) collects data based on the detection control information inserted in the service packet and reports the collected data to the analyzer.
  • the analyzer detects and identifies anomalies in the network based on the collected data reported by each device, so as to accurately detect the performance of each service, such as delay and packet loss, so that the network quality Service-Level Agreement (SLA: Service-Level Agreement) can be visualized in real time. To achieve rapid fault delimitation and location.
  • SLA Service-Level Agreement
  • the existing flow detection is limited to the same network domain, such as the SRv6 domain, the BIERv6 domain, etc. Once the service flow is forwarded across domains, the flow detection cannot be implemented.
  • the embodiments of the present application provide an on-flow detection method and an electronic device, so as to implement on-flow detection based on service packets forwarded across domains in a cross-forwarding scenario.
  • a flow detection method is applied to a network device, and the method includes:
  • the first service packet carries a first packet header, and the first packet header includes at least a first stream detection option, and the first stream detection option is determined by the first
  • the ingress node of the network domain is added to the first packet header, and the first on-flow detection option is used to indicate on-flow detection;
  • the second service packet is forwarded in the second network domain;
  • the second service packet is encapsulated in the outer layer of the first service packet obtained from the second packet header,
  • the second packet header carries at least a second on-stream detection option, and the second on-stream detection option is used to indicate that the same on-stream detection method is used as the first on-stream detection option
  • the same service flow is detected with the flow.
  • the second accompanying detection option is obtained by copying the first accompanying detection option; or, the detection control information field in the first accompanying detection option is the same as that of the second accompanying detection option.
  • the detection control information fields in the detection options all contain the same detection control information; the detection control information is used to indicate the service flow and the flow-accompanying detection mode.
  • the detection control information field includes at least: a FlowMonID field, which is used to indicate the service flow;
  • the flow detection mode field includes at least one of the following fields:
  • the FlowMonID Ext field is used to indicate the node identifier of the incoming node of the first network domain
  • the IOAM-Trace-type field is used to indicate the data type of the data detected with the flow.
  • the FlowMonID field occupies 20 bits.
  • the L field and the D field occupy 1 bit respectively.
  • the FlowMonID Ext field occupies 20 bits.
  • the IOAM-Trace-type field occupies 24 bits.
  • the detection control information field further includes: a Period field, which is used to indicate a period of flow detection.
  • the first on-stream detection option and the second on-stream detection option include other fields in addition to the detection control information field; the other fields include at least: a NextHeader field, which is used to indicate whether to carry Extended data type, when it is the first value, it means that no extended data type is carried, and when it is the second value, it means that the extended data type is carried; Extended data type TLVs field: used to indicate that the extended data type is carried when the NextHeader field is the second value data; the extended data at least includes: the identifier of the node through which the service message passes.
  • a NextHeader field which is used to indicate whether to carry Extended data type, when it is the first value, it means that no extended data type is carried, and when it is the second value, it means that the extended data type is carried
  • Extended data type TLVs field used to indicate that the extended data type is carried when the NextHeader field is the second value data
  • the extended data at least includes: the identifier of the node through which the service message passes.
  • the second packet header includes: an IPv6 extension header; the second flow-accompanying detection option is an option of a destination option extension header DOH in the IPv6 extension header.
  • This embodiment also provides an electronic device, the electronic device includes: a processor and a machine-readable storage medium;
  • the machine-readable storage medium stores machine-executable instructions executable by the processor
  • the processor is configured to execute machine-executable instructions to implement the method steps described above.
  • the ingress node of the second network domain receives the first service packet.
  • it does not simply encapsulate the first service packet based on the second network domain, but also refers to the first flow-accompanying detection option carried in the first service packet during encapsulation, so that the first service packet is outside the first service packet.
  • the packet header of the layer encapsulation carries the second on-flow detection option, which implements on-flow detection in the second network domain based on the second on-flow detection option, and implements on-flow detection when the first service packet is forwarded across domains.
  • FIG. 2 is a structural diagram of a detection control information field provided by an embodiment of the present application.
  • IPv6 extension header provided by an embodiment of the present application
  • IPv6 IPv6 basic header provided by an embodiment of the present application
  • Embodiment 1 is a schematic diagram of the networking of Embodiment 1 provided by the present application.
  • FIG. 6 is a structural diagram of an on-stream detection option provided by an embodiment of the present application.
  • Embodiment 7 is a schematic diagram of the networking of Embodiment 2 provided by the present application.
  • Fig. 8 is a device structure diagram provided by the application.
  • FIG. 9 is a hardware structure diagram of the apparatus provided by the present application.
  • FIG. 1 is a flowchart of a method provided by an embodiment of the present application. The method is applied to a network device, where the network device may be a router, a switch, or the like, which is not specifically limited in this embodiment.
  • the network device may be a router, a switch, or the like, which is not specifically limited in this embodiment.
  • the method may include the following steps:
  • Step 101 The network device receives a first service packet; the first service packet carries a first packet header; the first packet header includes at least a first flow-within detection option, and the first flow-with-detection option is provided by the first network. If the ingress node of the domain is added to the first packet header, the first on-flow detection option is used to indicate on-flow detection.
  • the first service packet and the first packet header are only named for convenience of description, and are not used for limitation. Going to this step 101, the first packet header is the outer packet header of the first service packet.
  • the ingress node of the first network domain when the ingress node of the first network domain receives the original service packet, it will identify whether the original service packet is a target that needs to be subjected to flow-inspection based on the pre-configured flow-aware detection method.
  • packet when the original service packet is identified as the target packet that needs to be subjected to flow detection, it will encapsulate the outer header carrying the first flow detection option in the outer layer of the original service packet (that is, the above-mentioned No. a header).
  • the ingress node of the first network domain encapsulates the first packet header carrying the first flow-accompanying detection option in the outer layer of the original service packet, it will be described below through specific embodiments, and will not be described here.
  • the original service packet encapsulated in the outer layer with the first header carrying the first flow-with-detection option is recorded as the above-mentioned first service packet, and then the ingress node of the first network domain is in the first network.
  • the domain forwards the first service message.
  • the above-mentioned network device may receive the first service message. Once the first service message is received, the foregoing step 101 is performed.
  • the first on-flow detection option is used to indicate on-flow detection, and specifically, it may indicate the service flow to which the first service packet belongs and the on-flow detection method.
  • the service flow to which the first service packet belongs may be identified by the source address and destination address of the original service packet.
  • the flow detection method an example will be described below, and details will not be repeated here.
  • Step 102 when the network device is the ingress node of the second network domain, forwards the second service packet in the second network domain; the second service packet is obtained by encapsulating the second packet header in the outer layer of the first service packet Obtained, the second packet header includes at least a second flow-attached detection option, and the second flow-attached detection option is used to indicate that the first flow-attached detection option is performed in the same flow-attached detection method and the same service flow is followed.
  • Flow detection when the network device is the ingress node of the second network domain, forwards the second service packet in the second network domain; the second service packet is obtained by encapsulating the second packet header in the outer layer of the first service packet Obtained, the second packet header includes at least a second flow-attached detection option, and the second flow-attached detection option is used to indicate that the first flow-attached detection option is performed in the same flow-attached detection method and the same service flow is followed.
  • This step 102 is performed on the premise that the network device is an ingress node of the second network domain.
  • the first packet header of the first service packet carries the first flow-accompanying detection option, indicating that the first service packet also Not leaving the first network domain, this means that the first service packet is forwarded across domains (that is, forwarded from the first network domain to the second network domain).
  • the network device will encapsulate the outer packet header in the outer layer of the first service packet.
  • the outer packet header encapsulated in the outer layer of the first service packet may be recorded as the second packet header.
  • the second packet header here is the outer packet header
  • the first packet header originally carried by the first service packet can be called the inner layer packet compared to the second packet header. head.
  • the first service packet encapsulated with the second packet header in the outer layer may be recorded as the second service packet.
  • the second packet header includes at least the second flow-accompanying detection option.
  • the second on-flow detection option is used to indicate that on-flow detection is performed in the second network domain.
  • the ingress node that is, the above-mentioned network device
  • the second service packet are The transit node that the second network domain passes through and the outgoing node of the second network domain will perform on-stream detection based on the second on-stream detection option.
  • both the second on-flow detection option and the first on-flow detection option implement on-flow detection on the same service flow in the same manner. Based on this, the second on-flow detection option is used to instruct the first on-flow detection option to perform on-flow detection on the same service flow according to the same on-flow detection method.
  • the process shown in FIG. 1 realizes that even if the first service packet is forwarded across domains, such as from the first network domain to the second network domain, when the ingress node of the second network domain receives the first service packet, it is not simple
  • the first service packet is encapsulated based on the second network domain, and the first flow-accompanying detection option is also carried in the first packet header according to the first service packet during encapsulation, so that the
  • the outer-layer packet header of the outer layer encapsulation carries the second on-flow detection option, which implements on-flow detection in the second network domain based on the second on-flow detection option, and implements on-flow detection when the first service packet is forwarded across domains detect
  • the above-mentioned second on-stream detection option is the same as the above-mentioned first on-stream detection option.
  • the second stream detection option can be obtained by copying the first stream detection option.
  • the above-mentioned second on-flow detection option may not be obtained by copying the first on-flow detection option, but requires at least the detection control information field in the above-mentioned second on-flow detection option and the first on-flow detection option All the detection control information fields in , all contain the same detection control information.
  • the detection control information is used to indicate the above-mentioned service flow and the above-mentioned flow-dependent detection method.
  • the detection control information field includes at least the following fields: a FlowMonID field and a flow detection mode field.
  • the FlowMonID field is used to indicate the service flow.
  • the FlowMonID field may occupy 20 bits.
  • the service flow can represent a service flow by the source address and the destination address together.
  • the field of flow detection mode is used to indicate the flow detection mode.
  • the flow detection mode field includes at least one of the following fields: an L field, a D field, a FlowMonID Ext field, and an IOAM-Trace-type field.
  • the L field is used to indicate the packet loss flag. For example, when the value of the packet loss flag is 1, such as 0, it indicates to perform packet loss detection; when the value of the packet loss flag is 2, such as 1, it indicates that no packet loss detection is performed.
  • the L field occupies 1 bit.
  • the D field is used to indicate the delay flag. For example, when the time delay flag takes a value of 3, such as 0, it indicates that the delay detection is performed, and when the time delay flag takes a value of 4, such as 1, it indicates that the delay detection is not performed.
  • the D field occupies 1 bit.
  • FlowMonID Ext field used to indicate the node identifier of the ingress node of the first network domain.
  • the FlowMonID Ext field occupies 20 bits.
  • the IOAM-Trace-type field is used to indicate the data type of the data detected with the flow.
  • the IOAM-Trace-type field occupies 24 bits, and each bit represents a data type.
  • a data type may include: the timestamp of the received packet. information, packet count information, etc.
  • FIG. 2 shows the structure of the detection control information field by taking the flow detection mode field including the L field, the D field, the FlowMonID Ext field, and the IOAM-Trace-type field as an example.
  • the foregoing detection control information field may further include: a Period field.
  • the Period field is used to indicate the period of flow detection.
  • the Period field occupies 8 bits. Still taking the use of flow-based detection to detect the delay as an example, the above-mentioned packet count information refers to the packet count information in a period.
  • the above-mentioned first on-flow detection option and the second on-flow detection option may include other fields in addition to the above-mentioned detection control information field.
  • other fields are: NextHeader field, extended data type TLVs field, etc.
  • the NextHeader field is used to indicate whether the extended data type is carried. When it is the first value, it means that the extended data type is not carried, and when it is the second value, it means that the extended data type is carried.
  • Extended data type TLVs field used to indicate that extended data is carried when the NextHeader field is the second value; the extended data at least includes: the identifier of the node through which the message passes.
  • the above-mentioned second packet header may include: an IPv6 extension header (Extension Header).
  • Extension Header shows an example of the structure of the IPv6 extension header.
  • the second stream detection option is an option of a Destination Option Header (DOH: Destination Option Header) in the IPv6 extension header.
  • DOH Destination Option Header
  • the above-mentioned IPv6 extension header further includes: a segment routing header (SRH: Segment Routing Header) .
  • SRH Segment Routing Header
  • the SRH is used to carry the path information of the second service packet forwarded in the second network domain, and its structure is similar to the encapsulation of the existing SRH.
  • the second packet header further includes: an IPv6 header (Header).
  • the IPv6 header here is different from the IPv6 extension header described above. Compared with the above-mentioned IPv6 extension header, the IPv6 header here may be recorded as the IPv6 basic header, and its structure is shown in FIG. 4 .
  • the IPv6 base header precedes the IPv6 extension header. The following uses an embodiment shown in FIG. 5 to illustrate the flow-independent detection of unicast packets.
  • the ingress node of the second network domain supports Bit Indexed Explicit Replication (BIER: Bit Indexed Explicit Replication)
  • BIER Bit Indexed Explicit Replication
  • the foregoing IPv6 extension header further includes: a BIER header.
  • BIER Bit-Forwarding Router
  • BFR Bit-Forwarding Router
  • the domain composed of BFRs is called a BIER domain
  • BFRs in the BIER domain are called BFIR and BFER, respectively.
  • the BFR in the BIER domain exchanges information such as the identity of the BFR, the BIER sub-domain where it is located, and the BIER forwarding capability by running the control plane protocol, and calculates and generates a bit index forwarding routing table (BIFT: Bit Index Forwarding Table) based on this information.
  • BIOS Bit Index Forwarding Table
  • BIFT consists of forwarding bit string mask F-BM and BFR neighbors. Each bit of F-BM represents a unique BFR in the BIER domain, and this information is defined by the BFR identifier BFR-id.
  • the BIER packet header carries the BFER set.
  • the BFER set may be represented by a bit string (BitString), where the bit bit set to 1 in the BitString indicates the corresponding BFER.
  • the BIER header may be another option in the above-mentioned DOH.
  • the second flow follow detection option in the above-mentioned DOH may be located before the BIER packet header.
  • the second on-flow detection option in the above-mentioned DOH may be located after the BIER packet header.
  • FIG. 5 is a schematic diagram of the networking of Embodiment 1 provided by the present application. This embodiment takes the flow-with-flow detection when SRv6 unicast packets are forwarded across domains as an example.
  • the device A1 serving as the ingress node in the first SRv6 domain receives the original SRv6 unicast packet (referred to as packet 501), it parses the packet characteristics such as source address, destination address, etc., based on the parsed packet If the packet 501 needs to be detected according to the preconfigured flow detection identification method, the packet header is encapsulated in the outer layer of the packet 501 (referred to as the first packet header).
  • the encapsulated first packet header may include an IPv6 basic header and an IPv6 extension header.
  • the IPv6 extension header includes at least DOH and SRH. Among them, DOH adds an option for flow detection, which is recorded as the first flow detection option.
  • FIG. 6 illustrates the structure of the first flow detection option by example.
  • the above-mentioned IPv6 basic header and the above-mentioned SRH are similar to the existing encapsulation methods, and will not be repeated here.
  • the flow follow detection is performed hop-by-hop as an example, and the DOH in the above-mentioned IPv6 extension header may be located before the SRH.
  • device A1 obtains corresponding data such as packet reception timestamp, packet count, etc. based on the data type indicated by the IOAM-Trace-type field in the first on-stream detection option, The data is reported to the analyzer.
  • the packet 501 encapsulated with the first packet header is denoted as the packet 502 in the above description.
  • the device A1 forwards the packet 502 to the device B1 based on the path information in the SRH carried in the packet 502 .
  • the device B1 After receiving the packet 502, the device B1 recognizes that the DOH of the packet 502 carries the first on-stream detection option, and obtains corresponding data such as a packet based on the data type indicated by the IOAM-Trace-type field in the first on-stream detection option. The received data is reported to the analyzer. After that, the device B1 forwards the packet 502 to the device C1 based on the path information in the SRH carried in the packet 502 .
  • device C1 is the ingress node of the second SRv6 domain.
  • device C1 receives packet 502, it recognizes that the DOH of packet 502 carries the first on-flow detection option, and based on the first on-flow detection option
  • the data type indicated by the IOAM-Trace-type field in the options is used to obtain the corresponding data, such as packet reception timestamp, packet count, etc., and report the obtained data to the analyzer.
  • the device C1 encapsulates the packet header (referred to as the second packet header) in the outer layer of the packet 502 .
  • the encapsulated second packet header may include an IPv6 basic header and an IPv6 extension header.
  • the IPv6 extension header in the second packet header includes at least DOH and SRH.
  • DOH adds an option for on-stream detection, which is denoted as the second on-stream detection option.
  • the second streaming detection option can be obtained by copying the first streaming detection option, or the detection control information field in the second streaming detection option is identical to the detection control information field in the first streaming detection option.
  • the included detection control information is the same, and the structure of the second flow-dependent detection option is similar to the structure of the first flow-dependent detection option shown in FIG. 6 .
  • the packet 502 encapsulated with the second packet header is denoted as a packet 503 in the foregoing description.
  • the IPv6 basic header in the above-mentioned outer layer packet header and the above-mentioned SRH are similar to the existing encapsulation methods, and will not be repeated here.
  • the device C1 forwards the packet 503 to the device D1 based on the path information in the SRH carried in the packet 503 .
  • the device D1 After receiving the packet 503, the device D1 recognizes that the DOH of the packet 503 carries the second on-stream detection option, and obtains the corresponding data such as the packet based on the data type indicated by the IOAM-Trace-type field in the second on-stream detection option. The received data is reported to the analyzer. After that, the device D1 forwards the packet 503 to the device E1 based on the path information in the SRH carried in the packet 503 .
  • the device E1 recognizes that the DOH of the packet 503 carries the second on-stream detection option, based on the IOAM-Trace-type field in the second on-stream detection option Obtain the corresponding data for the indicated data type, such as the time stamp of packet reception, packet count, etc., and report the acquired data to the analyzer. After that, the device E1 removes the second packet header of the packet 503 to restore the above-mentioned packet 502 , and forwards the packet 502 to the device F1 based on the path information in the SRH carried by the packet 502 .
  • the device F1 recognizes that the DOH of the packet 502 carries the first on-stream detection option, based on the IOAM-Trace-type field in the first on-stream detection option Obtain the corresponding data for the indicated data type, such as the time stamp of packet reception, packet count, etc., and report the acquired data to the analyzer. After that, the device F1 removes the above-mentioned inner packet header of the packet 502 to restore the above-mentioned packet 501, and continues to forward the packet 501.
  • the analyzer After receiving the data reported by the device A1 to the device F1, it summarizes and determines the entire forwarding performance data of the service flow to which the packet 501 belongs according to the existing detection method.
  • This embodiment does not specifically limit how the analyzer determines the overall forwarding performance data of the service flow, and reference may be made to the existing determination method.
  • Example 1 it can be seen from Example 1 that even if the SRv6 unicast message is forwarded from the first SRv6 domain to the second SRv6 domain, the ingress node of the second SRv6 domain, such as the above-mentioned device C1, receives the SRv6 unicast message from the first SRv6 domain.
  • a message such as the above-mentioned packet 502 is not simply encapsulated in the outer layer of an SRv6 unicast packet such as the above-mentioned packet 502 based on the second SRv6 domain, but also refers to the first accompanying flow carried by the packet 502 during encapsulation.
  • the detection option is encapsulated, so that the outer encapsulation of the SRv6 unicast packet such as the above-mentioned packet 502 carries at least the outer packet header of the second flow detection option, and finally the nodes in the second SRv6 domain are based on the outer packet.
  • the second on-stream detection option carried in the header performs on-stream detection, which implements on-stream detection when SRv6 unicast packets are forwarded across domains.
  • FIG. 7 is a schematic diagram of networking according to Embodiment 2 provided by the present application. This embodiment takes the flow-with-flow detection when SRv6 multicast packets are forwarded across domains as an example.
  • device A2 as the ingress node of the BIER domain, receives the original SRv6 multicast packet (denoted as packet 701), and parses the packet characteristics such as source address, destination address, etc., based on the parsed packet If the packet 701 needs to be detected according to the preconfigured flow detection identification method, the packet 701 is encapsulated with an outer packet header (referred to as the first packet header).
  • the encapsulated first packet header may include an IPv6 basic header and an IPv6 extension header.
  • the DOH in the IPv6 extension header includes two options, one of which is used for flow-inspection, which is recorded as the first flow-inspection option, and the other option is the BIER header.
  • the first flow-following detection option in the DOH is before the BIER packet header. Positional order in DOH. It should be noted that the above-mentioned IPv6 basic header and IPv6 extension header are similar to the existing encapsulation methods, and will not be repeated here.
  • the BIER packet header carries the BFER set, which is the set of outgoing nodes when the packet 701 leaves the BIER domain.
  • device A2 obtains corresponding data such as packet reception timestamp, packet count, etc., based on the data type indicated by the IOAM-Trace-type field in the first flow detection option, The data is reported to the analyzer.
  • packet 701 encapsulated with the packet header is denoted as packet 702 in the above description.
  • device A2 forwards the packet 702 to device B2 based on the BFER set in the BIER header carried in the packet 702 .
  • the device B2 After receiving the packet 702, the device B2 recognizes that the DOH of the packet 702 carries the first on-stream detection option, and obtains corresponding data such as a packet based on the data type indicated by the IOAM-Trace-type field in the first on-stream detection option. The received data is reported to the analyzer. Afterwards, the device B2 forwards the packet 702 to the device C2 based on the BFER set in the BIER header carried in the packet 702 .
  • device C2 is the ingress node of the SRv6 domain.
  • device C2 receives the packet 702 it recognizes that the DOH of the packet 702 carries the first on-flow detection option, based on the first on-flow detection option in the The data type indicated by the IOAM-Trace-type field obtains the corresponding data, such as packet reception timestamp, packet count, etc., and reports the obtained data to the analyzer.
  • the device C2 encapsulates the outer packet header (referred to as the second packet header) in the outer layer of the packet 702 .
  • the encapsulated second packet header may include an IPv6 basic header and an IPv6 extension header.
  • the IPv6 extension header in the second packet header includes DOH and SRH.
  • DOH and SRH an option is added to the DOH for on-stream detection, which is recorded as the second on-stream detection option.
  • the second streaming detection option can be obtained by copying the first streaming detection option, or the detection control information field in the second streaming detection option is identical to the detection control information field in the first streaming detection option.
  • the detection control information contained is the same.
  • the packet 702 encapsulated with the new packet header is denoted as packet 703 in the above description.
  • the SRH carries the path information for packet 703 to be forwarded in the SRv6 domain.
  • the IPv6 basic header in the above-mentioned outer layer packet header and the above-mentioned SRH are similar to the existing encapsulation methods, and will not be repeated here.
  • the device C2 forwards the packet 703 to the device D2 based on the path information in the SRH carried in the packet 703 .
  • the device D2 After receiving the packet 703, the device D2 recognizes that the DOH of the packet 703 carries the second on-stream detection option, and obtains the corresponding data such as a packet based on the data type indicated by the IOAM-Trace-type field in the second on-stream detection option. The received data is reported to the analyzer. Afterwards, the device D2 forwards the packet 703 to the device E2 based on the path information in the SRH carried in the packet 703 .
  • the device E2 recognizes that the DOH of the packet 703 carries the second on-stream detection option, based on the IOAM-Trace-type field in the second on-stream detection option.
  • the data type obtains the corresponding data, such as the message receiving timestamp, message count, etc., and reports the obtained data to the analyzer.
  • the device E2 removes the second header of the message 703 to restore the above-mentioned message 702 , and forwards the message 702 to the device F2 based on the BFER set in the BIER header carried by the message 702 .
  • the device F2 recognizes that the DOH of the packet 702 carries the first on-stream detection option, based on the IOAM-Trace-type field indicated in the first on-stream detection option.
  • the data type obtains the corresponding data, such as the message receiving timestamp, message count, etc., and reports the obtained data to the analyzer.
  • the device F2 removes the packet header of the packet 702 to restore the above-mentioned packet 701, and continues to forward the packet 701.
  • the analyzer after receiving the data reported by the device A2 to the device F2, it summarizes and determines the entire forwarding performance data of the service flow to which the message 701 belongs according to the existing detection method.
  • This embodiment does not specifically limit how the analyzer determines the overall forwarding performance data of the service flow, and reference may be made to the existing determination method.
  • Example 2 it can be seen from Example 2 that even if the SRv6 multicast packet is forwarded from the BIER domain to the SRv6 domain, the ingress node of the SRv6 domain, such as the above-mentioned device C2, receives the SRv6 multicast packet from the BIER domain, such as the above-mentioned report.
  • the message 702 does not simply encapsulate the received SRv6 multicast packet such as the above-mentioned packet 702 based on the SRv6 domain, but also refers to the SRv6 multicast packet such as the first stream carried by the packet 702 during encapsulation.
  • the detection option is made so that the outer encapsulation of the SRv6 multicast packet such as the above-mentioned packet 702 contains at least the outer packet header of the second flow detection option, and finally the nodes in the SRv6 domain are based on the first packet carried in the outer packet header.
  • the second option of on-stream detection enables on-stream detection, which implements on-stream detection when SRv6 multicast packets are forwarded across domains.
  • FIG. 8 is a structural diagram of an apparatus provided by an embodiment of the present application.
  • the device is applied to network equipment, as shown in Figure 8, the device may include:
  • a receiving unit configured to receive a first service packet; the first service packet carries a first packet header, and the first packet header includes at least a first flow-dependent detection option, and the first flow-dependent detection option The option is added to the first packet header by the ingress node of the first network domain, and the first on-flow detection option is used to indicate on-flow detection;
  • a cross-domain forwarding unit configured to forward a second service packet in the second network domain when the network device is an ingress node of the second network domain; the second service packet is sent through the first
  • the outer layer of the service packet encapsulates a second packet header, and the second packet header includes at least a second on-flow detection option, and the second on-flow detection option is used to indicate the same as the first on-flow detection option.
  • on-stream detection is performed on the same service flow.
  • the second stream detection option is obtained by copying the first stream detection option.
  • the detection control information field includes at least:
  • the FlowMonID field is used to indicate the business flow
  • the field of flow detection mode is used to indicate the flow detection mode.
  • the flow detection mode field includes at least one of the following fields:
  • the FlowMonID Ext field is used to indicate the node identifier of the incoming node of the first network domain
  • the IOAM-Trace-type field is used to indicate the data type of the data detected with the flow.
  • the FlowMonID field occupies 20 bits.
  • the L field and the D field occupy 1 bit respectively.
  • the FlowMonID Ext field occupies 20 bits.
  • the IOAM-Trace-type field occupies 24 bits.
  • the detection control information field further includes:
  • the Period field is used to indicate the period of flow detection.
  • the first stream detection option and the second stream detection option include other fields in addition to the detection control information field; wherein the other fields include at least:
  • the NextHeader field is used to indicate whether to carry the extended data type, when it is the first value, it means that the extended data type is not carried, and when it is the second value, it means that the extended data type is carried;
  • Extended data type TLVs field used to indicate that extended data is carried when the NextHeader field is the second value; the extended data at least includes: the identifier of the node through which the message passes.
  • the second packet header includes: an IPv6 extension header.
  • the second stream detection option is an option of the DOH in the IPv6 extension header.
  • the DOH further includes another option.
  • the other option is an explicit copy of the BIER header of the bit index, and the BIER header is used to carry the second service message and forward it in the second network domain. forwarding information.
  • the second flow follow detection option in the above DOH is before the BIER packet header.
  • the second on-flow detection option in the above-mentioned DOH is located after the BIER packet header.
  • the IPv6 extension header further includes an SRH; the SRH is used to carry path information for forwarding the second service packet in the second network domain.
  • the DOH in the IPv6 extension header is before the SRH.
  • the end-to-end flow follower detection is performed, the above-mentioned DOH in the above-mentioned Pv6 extension header is located after the SRH.
  • FIG. 9 is a structural diagram of an electronic device provided by an embodiment of the present application.
  • the hardware structure may include: a processor and a machine-readable storage medium, where the machine-readable storage medium stores machine-executable instructions that can be executed by the processor; the processor is configured to execute machine-executable instructions instructions to implement the methods disclosed in the above examples of this application.
  • an embodiment of the present application further provides a machine-readable storage medium, where several computer instructions are stored on the machine-readable storage medium, and when the computer instructions are executed by a processor, the present invention can be implemented. Apply the methods disclosed in the above examples.
  • the above-mentioned machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that may contain or store information, such as executable instructions, data, and the like.
  • the machine-readable storage medium can be: RAM (Radom Access Memory, random access memory), volatile memory, non-volatile memory, flash memory, storage drive (such as hard disk drive), solid state drive, any type of storage disk (such as compact disc, dvd, etc.), or similar storage media, or a combination thereof.
  • a typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, wearable device, or a combination of any of these devices.
  • the embodiments of the present application may be provided as a method, a system, or a computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • these computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer readable memory result in an article of manufacture comprising the instruction means,
  • the instruction means implements the functions specified in a flow or flows of the flowcharts and/or a block or blocks of the block diagrams.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请提供了随流检测方法和电子设备。本申请中，即使第一业务报文跨域转发比如从第一网络域跨至第二网络域转发，第二网络域的入节点在接收到第一业务报文时，并非简单地基于第二网络域对第一业务报文进行封装，而是在封装时还参考第一业务报文携带的第一随流检测选项以使在第一业务报文的外层封装的报文头携带第二随流检测选项，实现基于第二随流检测选项在第二网络域进行随流检测，实现了第一业务报文跨域转发时的随流检测。

Description

随流检测方法和电子设备 技术领域
本申请涉及网络通信技术领域，特别涉及随流检测方法和电子设备。
背景技术
随流检测(IOAM：In-situ OAM)是指利用正常转发的业务报文进行的网络检测。随流检测可由网络设备和分析器相互配合完成，具体可通过以下方式实现：
作为入节点(Ingress)的网络设备在业务报文中插入检测控制信息，并基于业务报文中插入的检测控制信息采集数据并将采集的数据上报给分析器。作为传输节点(Transmit)或者出节点(Egress)的网络设备基于业务报文中插入的检测控制信息采集数据并将采集的数据上报给分析器。分析器基于各设备上报的采集数据检测识别网络中的异常，以实现精准检测每个业务的时延、丢包等性能，使得网络质量服务等级协议(SLA：Service-Level Agreement)实时可视，做到快速故障定界和定位。
但是，现有的随流检测都被限制在同一网络域比如SRv6域、BIERv6域等，一旦业务流跨域转发，则无法实现随流检测。
发明内容
本申请实施例提供了随流检测方法和电子设备，以在跨越转发场景中基于跨域转发的业务报文实现随流检测。
作为一个实施例，本申请实施例是通过如下技术方案实现的：
一种随流检测方法，该方法应用于网络设备，该方法包括：
接收第一业务报文；所述第一业务报文携带第一报文头，所述第一报文头中至少包括第一随流检测选项，所述第一随流检测选项是由第一网络域的入节点添加至所述第一报文头，所述第一随流检测选项用于指示随流检测；
当所述网络设备为第二网络域的入节点时，在所述第二网络域内转发第二业务报文；所述第二业务报文是通过在所述第一业务报文的外层封装第二报文头得到的，所述第二报文头至少携带第二随流检测选项，所述第二随流检测选项用于指示与所述第一随流检测选项按照同一随流检测方式并对同一业务流进行随流检测。
可选地，所述第二随流检测选项是通过对所述第一随流检测选项进行拷贝得到；或者，所述第一随流检测选项中的检测控制信息字段与所述第二随流检测选项中的检测控制信息字段均包含相同的检测控制信息；所述检测控制信息用于指示所述业务流、以及所述随流检测方式。
可选地，所述检测控制信息字段至少包括：FlowMonID字段，用于指示业务流；随流检测方式字段，用于指示随流检测方式。
可选地，所述随流检测方式字段包括以下至少一个字段：
L字段，用于指示丢包标记；
D字段，用于指示时延标记；
FlowMonID Ext字段，用于指示所述第一网络域的入节点的节点标识；
IOAM-Trace-type字段，用于指示随流检测的数据的数据类型。
可选地，所述FlowMonID字段占用20bits。
可选地，所述L字段、所述D字段分别占用1bit。
可选地，所述FlowMonID Ext字段占用20bits。
可选地，所述IOAM-Trace-type字段占用24bits。
可选地，所述检测控制信息字段还包括：Period字段，用于指示随流检测的周期。
可选地，所述第一随流检测选项、所述第二随流检测选项除了所述检测控制信息字段之外还包含其他字段；所述其他字段至少包括：NextHeader字段，用于指示是否携带扩展数据类型，当为第一值时表示未携带扩展数据类型，当为第二值时表示携带扩展数据类型；扩展数据类型TLVs字段：用于在所述NextHeader字段为第二值时指示携带扩展数据；所述扩展数据至少包括：业务报文经由的节点的标识。
可选地，所述第二报文头包括：IPv6扩展头；所述第二随流检测选项为所述IPv6扩展头中目的选项扩展头DOH的一个选项。
本实施例还提供一种电子设备，该电子设备包括：处理器和机器可读存储介质；
所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令；
所述处理器用于执行机器可执行指令，以实现上述方法步骤。
通过本申请的以上技术方案，在本申请中，即使第一业务报文跨域转发比如从第一 网络域跨至第二网络域转发，第二网络域的入节点在接收到第一业务报文时，并非简单地基于第二网络域对第一业务报文进行封装，而是在封装时还参考第一业务报文携带的第一随流检测选项以使在第一业务报文的外层封装的报文头携带第二随流检测选项，实现基于第二随流检测选项在第二网络域进行随流检测，实现了第一业务报文跨域转发时的随流检测。
附图说明
图1为本申请实施例提供的方法流程图；
图2为本申请实施例提供的检测控制信息字段结构图；
图3为本申请实施例提供的IPv6扩展头示意图；
图4为本申请实施例提供的IPv6基础头示意图；
图5为本申请提供的实施例1的组网示意图；
图6为本申请实施例提供的随流检测选项结构图；
图7为本申请提供的实施例2的组网示意图；
图8为本申请提供的装置结构图；
图9为本申请提供的装置的硬件结构图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
为了使本领域技术人员更好地理解本申请实施例提供的技术方案，并使本申请实施例的上述目的、特征和优点能够更加明显易懂，下面结合附图对本申请实施例中技术方案作进一步详细的说明。
参见图1，图1为本申请实施例提供的方法流程图。该方法应用于网络设备，这里 的网络设备可为路由器、交换机等，本实施例并不具体限定。
如图1所示，该方法可包括以下步骤：
步骤101，网络设备接收第一业务报文；第一业务报文携带第一报文头；第一报文头中至少包括第一随流检测选项，第一随流检测选项是由第一网络域的入节点添加至所述第一报文头的，第一随流检测选项用于指示随流检测。
这里，第一业务报文、第一报文头只是为便于描述而进行的命名，并非用于限定。执行到本步骤101，第一报文头为第一业务报文的外层报文头。
可选地，在本实施例中，第一网络域的入节点在接收到原始业务报文时，会基于预先配置的随流检测方式识别出原始业务报文是否为需要进行随流检测的目标报文，当识别出原始业务报文为需要进行随流检测的目标报文，则会在原始业务报文的外层封装携带第一随流检测选项的外层报文头(即上述的第一报文头)。至于第一网络域的入节点如何在原始业务报文的外层封装携带了第一随流检测选项的第一报文头，下文会通过具体实施例描述，这里暂不赘述。
为便于描述，这里将在外层封装了携带第一随流检测选项的第一报文头的原始业务报文记为上述的第一业务报文，之后第一网络域的入节点在第一网络域转发第一业务报文，在转发过程中，上述的网络设备有可能会收到第一业务报文，一旦收到第一业务报文，则执行上述的步骤101。
在本实施例中，第一随流检测选项用于指示随流检测，具体地，其可指示第一业务报文所属的业务流、以及随流检测方式。可选地，在本实施例中，第一业务报文所属的业务流可通过原始业务报文的源地址和目的地址来标识。至于随流检测方式，下文会举例描述，这里暂不赘述。
步骤102，当网络设备为第二网络域的入节点时，在第二网络域内转发第二业务报文；第二业务报文是通过在第一业务报文的外层封装第二报文头得到的，所述第二报文头至少包括第二随流检测选项，所述第二随流检测选项用于指示与第一随流检测选项按照同一随流检测方式并对同一业务流进行随流检测。
本步骤102是在网络设备为第二网络域的入节点的前提下执行的。当网络设备作为第二网络域的入节点时接收到的第一业务报文如上描述第一业务报文的第一报文头携带了第一随流检测选项，则表示第一业务报文还未离开第一网络域，此时意味着第一业务报文是跨域转发(即从第一网络域跨至第二网络域转发)。在此种情况下，如步骤102 描述，网络设备会在第一业务报文的外层封装外层报文头。为便于区分，这里在第一业务报文的外层封装的外层报文头可记为第二报文头。此时，这里的第二报文头就为外层报文头，而第一业务报文原来携带的第一报文头相比第二报文头而言，就可称为内层报文头。为便于区分，此时可将在外层封装了第二报文头的第一业务报文记为第二业务报文。
在本实施例中，第二报文头至少包括第二随流检测选项。第二随流检测选项用于指示在第二网络域中进行随流检测。在本实施例中，一旦在第二业务报文的第二报文头携带第二随流检测选项，则第二网络域的入节点(也即上述的网络设备)、第二业务报文在第二网络域经由的传输节点、第二网络域的出节点就会基于第二随流检测选项进行随流检测。
在本实施例中，第二随流检测选项和第一随流检测选项均通过相同方式实现对同一业务流的随流检测。基于此，第二随流检测选项用于指示与所述第一随流检测选项按照同一随流检测方式并对同一业务流进行随流检测。
通过图1所示流程实现了即使第一业务报文跨域转发比如从第一网络域跨至第二网络域转发，第二网络域的入节点在接收到第一业务报文时，并非简单地基于第二网络域对第一业务报文进行封装，而是在封装时还依据第一业务报文在第一报文头携带第一随流检测选项，以使在第一业务报文的外层封装的外层报文头携带第二随流检测选项，实现了基于第二随流检测选项在第二网络域进行随流检测，实现了第一业务报文跨域转发时的随流检测
作为一个实施例，上述第二随流检测选项与上述第一随流检测选项相同。可选地，第二随流检测选项可通过拷贝第一随流检测选项得到。
作为另一个实施例，上述第二随流检测选项也可不是通过拷贝第一随流检测选项得到，而是至少要求上述第二随流检测选项中的检测控制信息字段与第一随流检测选项中的检测控制信息字段均包含相同的检测控制信息即可。这里，检测控制信息用于指示上述业务流以及上述随流检测方式。
可选地，在本实施例中，检测控制信息字段至少包括以下字段：FlowMonID字段、随流检测方式字段。
其中，FlowMonID字段，用于指示业务流。可选地，FlowMonID字段可占用20bits。这里，业务流可通过源地址和目的地址一起表示一条业务流。
随流检测方式字段，用于指示随流检测方式。在本实施例中，随流检测方式字段包括以下至少一个字段：L字段、D字段、FlowMonID Ext字段、IOAM-Trace-type字段。
其中，L字段，用于指示丢包标记。比如，当丢包标记取值为数值1比如0时，指示执行丢包检测，当丢包标记取值为数值2比如1时，指示不执行丢包检测。可选地，在本实施例中，L字段占用1bit。
D字段，用于指示时延标记。比如，当时延标记取值为数值3比如0时，指示执行时延检测，当时延标记取值为数值4比如1时，指示不执行时延检测。可选地，在本实施例中，D字段占用1bit。
FlowMonID Ext字段，用于指示第一网络域的入节点的节点标识。可选地，FlowMonID Ext字段占用20bits。
IOAM-Trace-type字段，用于指示随流检测的数据的数据类型。可选地，IOAM-Trace-type字段占用24bits，每一bit代表一种数据类型，比如以随流检测用于检测时延为例，则这样的数据类型可包括：接收到报文的时间戳信息、报文计数信息等。
图2以随流检测方式字段包括L字段、D字段、FlowMonID Ext字段、IOAM-Trace-type字段为例举例示出了检测控制信息字段的结构。
作为一个实施例，上述检测控制信息字段还可进一步包括：Period字段。这里，Period字段用于指示随流检测的周期。作为一个实施例，Period字段占用8bits。仍以随流检测用于检测时延为例，则上述的报文计数信息是指在一个周期内的报文计数信息。
可选的，作为一个实施例，上述第一随流检测选项、第二随流检测选项除了包括上述检测控制信息字段之外还可包括其他字段。比如，其他字段为：NextHeader字段、扩展数据类型TLVs字段等。
其中，NextHeader字段，用于指示是否携带扩展数据类型，当为第一值时表示未携带扩展数据类型，当为第二值时表示携带扩展数据类型。
扩展数据类型TLVs字段：用于在NextHeader字段为第二值时指示携带扩展数据；扩展数据至少包括：报文经由的节点的标识。
应用于IPv6场景，上述第二报文头可包括：IPv6扩展头(Extension Header)。图3举例示出了IPv6扩展头的结构。作为一个实施例，第二随流检测选项为IPv6扩展头中目的选项扩展头(DOH：Destination Option Header)的一个选项。
作为一个实施例，假如第一业务报文为单播报文，第二网络域为IPv6段路由(SR：Segment Routing)，则上述IPv6扩展头还包括：段路由扩展头(SRH：Segment Routing Header)。在本实施例中，当执行逐跳随流检测时，上述IPv6扩展头中上述DOH处于SRH之前。而当执行端到端随流检测时，上述Pv6扩展头中上述DOH处于SRH之后。在本实施例中，SRH用于携带第二业务报文在第二网络域转发的路径信息，其结构类似现有SRH的封装。
需要说明的是，本实施例中，可选地，上述第二报文头还包括：IPv6头(Header)。这里的IPv6头不同于上述的IPv6扩展头。相对于上述的IPv6扩展头，这里的IPv6头可记为IPv6基础头，其结构如图4所示。在一个例子中，在第二报文头中，IPv6基础头处于IPv6扩展头之前。下文通过图5所示的一个实施例举例示出单播报文的随流检测。
作为另一个实施例，假若第一业务报文为组播报文，第二网络域的入节点支持比特索引的显式复制(BIER：Bit Indexed Explicit Replication)，第二网络域为BIER域，则上述IPv6扩展头还包括：BIER报文头。
BIER是一种基于位索引显式复制的新型组播技术，该技术不需要显式建立组播分发树，也不需要中间节点保存任何组播流状态。具有BIER能力的路由器称之为位转发路由器(BFR：Bit-Forwarding Router)，BFR组成的域称之为BIER域，BIER域中处于边缘的BFR分别称之为BFIR和BFER。BIER域内的BFR通过运行控制面协议交换BFR的标识、所在BIER子域以及BIER转发能力等信息，并基于这些信息计算生成位索引转发路由表(BIFT：Bit Index Forwarding Table)。BIFT由转发位串掩码F-BM和BFR邻居组成，F-BM的每一位表示BIER域中唯一一个BFR，该信息由BFR的标识BFR-id定义。当组播报文进入BIER域时，BFIR确定该组播报文在BIER域内的BFER集合，然后在组播报文封装BIER报文头，当组播报文达到BFER时，BFER解封装BIER头并继续执行组播路由转发。下文会通过图7所示实施例描述组播报文转发，这里暂不赘述。
在本实施例中，BIER报文头携带了BFER集合。可选地，在本实施例中，BFER集合可通过比特串(BitString)表示，其中，当BitString中置1的bit位指示对应的BFER。
作为一个实施例，BIER报文头可为上述DOH中的另一选项。可选地，在本实施例中，当执行逐跳随流检测时，上述DOH中第二随流检测选项可处于BIER报文头之前。而当执行端到端随流检测时，上述DOH中第二随流检测选项可处于BIER报文头之后。
下面结合两个实施例对图1所示流程进行描述：
实施例1：
参见图5，图5为本申请提供的实施例1的组网示意图。本实施例是以SRv6单播报文跨域转发时的随流检测为例。
如图5所示，第一SRv6域中作为入节点的设备A1接收到原始SRv6单播报文(记为报文501)，则解析报文特征比如源地址、目的地址等，基于解析出的报文特征并按照预先配置的随流检测识别方式识别出报文501需要进行随流检测，则在报文501的外层封装报文头(记为第一报文头)。封装的第一报文头可包括IPv6基础头、IPv6扩展头。其中，IPv6扩展头中至少包括DOH和SRH。其中，DOH增加了一个选项用于随流检测，记为第一随流检测选项。可选地，基于上面描述的随流检测选项的结构，图6举例示出了第一随流检测选项的结构。需要说明的是，上述IPv6基础头、以及上述SRH类似现有的封装方式，不再赘述。本实施例以逐跳进行随流检测为例，则上述IPv6扩展头中DOH可处于SRH之前。
在图5所示的实施例中，设备A1基于第一随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。
为便于描述，上述将封装了第一报文头的报文501记为报文502。
之后，设备A1基于报文502携带的SRH中的路径信息转发报文502至设备B1。
设备B1收到报文502后，识别出报文502的DOH携带了第一随流检测选项，则基于第一随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备B1基于报文502携带的SRH中的路径信息转发报文502至设备C1。
如图5所示，设备C1为第二SRv6域的入节点，当设备C1收到报文502时，识别出报文502的DOH携带了第一随流检测选项，则基于第一随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备C1在报文502的外层封装报文头(记为第二报文头)。封装的第二报文头可包括IPv6基础头、IPv6扩展头。
在本实施例中，第二报文头中的IPv6扩展头至少包括DOH和SRH。其中，DOH增加了一个选项用于随流检测，记为第二随流检测选项。可选地，第二随流检测选项可 通过对第一随流检测选项拷贝得到，或者，第二随流检测选项中的检测控制信息字段与第一随流检测选项中的检测控制信息字段所包含的检测控制信息相同，第二随流检测选项的结构类似图6所示的第一随流检测选项的结构。为便于描述，上述将封装了第二报文头的报文502记为报文503。需要说明的是，上述外层报文头中IPv6基础头、以及上述SRH类似现有的封装方式，不再赘述。
之后，设备C1基于报文503携带的SRH中的路径信息转发报文503至设备D1。
设备D1收到报文503后，识别出报文503的DOH携带了第二随流检测选项，则基于第二随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备D1基于报文503携带的SRH中的路径信息转发报文503至设备E1。
设备E1作为第二SRv6域的出节点，在收到报文503后，识别出报文503的DOH携带了第二随流检测选项，则基于第二随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备E1去除报文503的第二报文头恢复出上述的报文502，基于报文502携带的SRH中的路径信息转发报文502至设备F1。
设备F1作为第一SRv6域的出节点，在收到报文502后，识别出报文502的DOH携带了第一随流检测选项，则基于第一随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备F1去除报文502的上述内层报文头恢复出上述的报文501，继续转发报文501。
至于分析器,其在接收到设备A1至设备F1上报的数据后，按照现有的检测方式汇总并确定报文501所属的业务流的全程转发性能数据。本实施例并不具体限定分析器如何确定业务流的全程转发性能数据，其可参见现有的确定方式。
通过实施例1可以看出，即使SRv6单播报文从第一SRv6域跨至第二SRv6域转发，第二SRv6域的入节点比如上述的设备C1在接收到来自第一SRv6域的SRv6单播报文比如上述的报文502，其并非简单地基于第二SRv6域在SRv6单播报文比如上述的报文502的外层进行封装，而是在封装时还参考报文502携带的第一随流检测选项进行封装，以使在SRv6单播报文比如上述的报文502的外层封装至少携带了第二随流检测选项的外层报文头，最终第二SRv6域中的节点基于外层报文头携带的第二随流检测选项进行 随流检测，实现了SRv6单播报文跨域转发时的随流检测。
以上以SRv6单播报文跨域转发为例通过实施例1进行了描述，下面以SRv6组播报文为例通过实施例2进行描述：
实施例2：
参见图7，图7为本申请提供的实施例2的组网示意图。本实施例是以SRv6组播报文跨域转发时的随流检测为例。
如图7所示，设备A2作为BIER域的入节点，在接收到原始SRv6组播报文(记为报文701)，则解析报文特征比如源地址、目的地址等，基于解析出的报文特征并按照预先配置的随流检测识别方式识别出报文701需要进行随流检测，则在报文701的外层封装外层报文头(记为第一报文头)。封装的第一报文头可包括IPv6基础头、IPv6扩展头。IPv6扩展头中的DOH包括两个选项，其中一个选项用于随流检测，记为第一随流检测选项，另一个选项为BIER报文头。本实施例中的随流检测假若为逐跳随流检测，则DOH中第一随流检测选项在BIER报文头之前，图7举例示出了第一随流检测选项和BIER报文头在DOH中的位置顺序。需要说明的是，上述IPv6基础头、IPv6扩展头类似现有的封装方式，不再赘述。BIER报文头携带了BFER集合，BFER集合为报文701离开BIER域时的出节点的集合。
在图7所示的实施例中，设备A2基于第一随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。
为便于描述，上述将封装了报文头的报文701记为报文702。
之后，设备A2基于报文702携带的BIER报文头中的BFER集合转发报文702至设备B2。
设备B2收到报文702后，识别出报文702的DOH携带了第一随流检测选项，则基于第一随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备B2基于报文702携带的BIER报文头中的BFER集合转发报文702至设备C2。
如图7所示，设备C2为SRv6域的入节点，当设备C2收到报文702时，识别出报文702的DOH携带了第一随流检测选项，则基于第一随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数 据上报至分析器。之后，设备C2在报文702的外层封装外层报文头(记为第二报文头)。封装的第二报文头可包括IPv6基础头、IPv6扩展头。
在本实施例中，第二报文头中IPv6扩展头包括DOH和SRH。其中的DOH增加了一个选项用于随流检测，记为第二随流检测选项。可选地，第二随流检测选项可通过对第一随流检测选项拷贝得到，或者，第二随流检测选项中的检测控制信息字段与第一随流检测选项中的检测控制信息字段所包含的检测控制信息相同。为便于描述，上述将封装了新的报文头的报文702记为报文703。SRH携带了报文703在SRv6域转发的路径信息。需要说明的是，上述外层报文头中IPv6基础头、以及上述SRH类似现有的封装方式，不再赘述。
之后，设备C2基于报文703携带的SRH中的路径信息转发报文703至设备D2。
设备D2收到报文703后，识别出报文703的DOH携带了第二随流检测选项，则基于第二随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备D2基于报文703携带的SRH中的路径信息转发报文703至设备E2。
设备E2作为SRv6域的出节点，在收到报文703后，识别出报文703的DOH携带了第二随流检测选项，则基于第二随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备E2去除报文703的第二报文头恢复出上述的报文702，基于报文702携带的BIER报文头中的BFER集合转发报文702至设备F2。
设备F2作为BIER域的出节点，在收到报文702后，识别出报文702的DOH携带了第一随流检测选项，则基于第一随流检测选项中IOAM-Trace-type字段指示的数据类型获取对应的数据比如报文接收时间戳、报文计数等，将获取到的数据上报至分析器。之后，设备F2去除报文702的报文头恢复出上述的报文701，继续转发报文701。
至于分析器,其在接收到设备A2至设备F2上报的数据后,按照现有的检测方式汇总并确定报文701所属的业务流的全程转发性能数据。本实施例并不具体限定分析器如何确定业务流的全程转发性能数据，其可参见现有的确定方式。
通过实施例2可以看出，即使SRv6组播报文从BIER域跨域至SRv6域转发，SRv6域的入节点比如上述的设备C2在接收到来自BIER域的SRv6组播报文比如上述的报文702，其并非简单地基于SRv6域对接收到的SRv6组播报文比如上述的报文702 进行封装，而是在封装时还参考SRv6组播报文比如报文702携带的第一随流检测选项以使在SRv6组播报文比如上述的报文702的外层封装至少包含第二随流检测选项的外层报文头，最终SRv6域中的节点基于外层报文头携带的第二随流检测选项即可进行随流检测，实现了SRv6组播报文跨域转发时的随流检测。
以上对本申请实施例提供的方法进行了描述，下面对本申请实施例提供的装置进行描述：
参见图8，图8为本申请实施例提供的装置结构图。该装置应用于网络设备，如图8所示，该装置可包括：
接收单元，用于接收第一业务报文；所述第一业务报文携带第一报文头，所述第一报文头中至少包括第一随流检测选项，所述第一随流检测选项是由第一网络域的入节点添加至所述第一报文头，所述第一随流检测选项用于指示随流检测；
跨域转发单元，用于当所述网络设备为第二网络域的入节点时，在所述第二网络域内转发第二业务报文；所述第二业务报文是通过在所述第一业务报文的外层封装第二报文头得到，所述第二报文头至少包括第二随流检测选项，所述第二随流检测选项用于指示与所述第一随流检测选项按照同一随流检测方式并对同一业务流进行随流检测。
可选地，在本实施例中，所述第二随流检测选项是通过对所述第一随流检测选项进行拷贝得到；或者，
所述第一随流检测选项中的检测控制信息字段与所述第二随流检测选项中的检测控制信息字段均包含相同的检测控制信息；所述检测控制信息用于指示所述业务流、以及所述随流检测方式。
可选地，在本实施例中，述检测控制信息字段至少包括：
FlowMonID字段，用于指示业务流；
随流检测方式字段，用于指示随流检测方式。
其中，随流检测方式字段包括以下至少一个字段：
L字段，用于指示丢包标记；
D字段，用于指示时延标记；
FlowMonID Ext字段，用于指示所述第一网络域的入节点的节点标识；
IOAM-Trace-type字段，用于指示随流检测的数据的数据类型。
可选地，在本实施例中，FlowMonID字段占用20bits。
可选地，在本实施例中，L字段、D字段分别占用1bit。
可选地，在本实施例中，FlowMonID Ext字段占用20bits。
可选地，在本实施例中，IOAM-Trace-type字段占用24bits。
可选地，在本实施例中，检测控制信息字段还包括：
Period字段，用于指示随流检测的周期。
可选地，在本实施例中，第一随流检测选项、第二随流检测选项除了包括检测控制信息字段之外还包括其他字段；其中，其他字段至少包括：
NextHeader字段，用于指示是否携带扩展数据类型，当为第一值时表示未携带扩展数据类型，当为第二值时表示携带扩展数据类型；
扩展数据类型TLVs字段：用于在NextHeader字段为第二值时指示携带扩展数据；扩展数据至少包括：报文经由的节点的标识。
可选地，在本实施例中，第二报文头包括：IPv6扩展头。其中，第二随流检测选项为IPv6扩展头中DOH的一个选项。
可选地，在本实施例中，DOH还包括另一选项，另一选项为比特索引的显式复制BIER报文头，BIER报文头用于携带第二业务报文在第二网络域转发的转发信息。当执行逐跳随流检测时，上述DOH中第二随流检测选项处于BIER报文头之前。而当执行端到端随流检测时，上述DOH中第二随流检测选项处于BIER报文头之后。
可选地，在本实施例中，所述IPv6扩展头还包括SRH；SRH用于携带第二业务报文在第二网络域转发的路径信息。可选地，当执行逐跳随流检测时，上述IPv6扩展头中上述DOH处于SRH之前。而当执行端到端随流检测时，上述Pv6扩展头中上述DOH处于SRH之后。
至此，完成图8所示装置的结构描述。
本申请实施例还提供了图8所示装置的硬件结构。参见图9，图9为本申请实施例提供的电子设备结构图。如图9所示，该硬件结构可包括：处理器和机器可读存储介质，机器可读存储介质存储有能够被所述处理器执行的机器可执行指令；所述处理器用 于执行机器可执行指令，以实现本申请上述示例公开的方法。
基于与上述方法同样的申请构思，本申请实施例还提供一种机器可读存储介质，所述机器可读存储介质上存储有若干计算机指令，所述计算机指令被处理器执行时，能够实现本申请上述示例公开的方法。
示例性的，上述机器可读存储介质可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可以由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
而且，这些计算机程序指令也可以存储在能引导计算机或其它可编程数据处理 设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或者多个流程和/或方框图一个方框或者多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或者其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (10)

  1. 一种随流检测方法，其特征在于，该方法应用于网络设备，该方法包括：
    接收第一业务报文；所述第一业务报文携带第一报文头，所述第一报文头中至少包括第一随流检测选项，所述第一随流检测选项是由第一网络域的入节点添加至所述第一报文头，所述第一随流检测选项用于指示随流检测；
    当所述网络设备为第二网络域的入节点时，在所述第二网络域内转发第二业务报文；所述第二业务报文是通过在所述第一业务报文的外层封装第二报文头得到，所述第二报文头至少包括第二随流检测选项，所述第二随流检测选项用于指示与所述第一随流检测选项按照同一随流检测方式并对同一业务流进行随流检测。
  2. 根据权利要求1所述的方法，其特征在于，所述第二随流检测选项是通过对所述第一随流检测选项进行拷贝得到；
    或者，
    所述第一随流检测选项中的检测控制信息字段与所述第二随流检测选项中的检测控制信息字段均包含相同的检测控制信息；所述检测控制信息用于指示所述业务流、以及所述随流检测方式。
  3. 根据权利要求2所述的方法，其特征在于，所述检测控制信息字段至少包括：
    FlowMonID字段，用于指示业务流；
    随流检测方式字段，用于指示随流检测方式。
  4. 根据权利要求3所述的方法，其特征在于，所述随流检测方式字段包括以下至少一个字段：
    L字段，用于指示丢包标记；
    D字段，用于指示时延标记；
    FlowMonID Ext字段，用于指示所述第一网络域的入节点的节点标识；
    IOAM-Trace-type字段，用于指示随流检测的数据的数据类型。
  5. 根据权利要求3所述的方法，其特征在于，
    所述FlowMonID字段占用20bits。
  6. 根据权利要求4所述的方法，其特征在于，
    所述L字段、所述D字段分别占用1bit；和/或，
    所述FlowMonID Ext字段占用20bits；和/或，
    所述IOAM-Trace-type字段占用24bits。
  7. 根据权利要求3所述的方法，其特征在于，所述检测控制信息字段还包括：
    Period字段，用于指示随流检测的周期。
  8. 根据权利要求2所述的方法，其特征在于，所述第一随流检测选项、所述第二随流检测选项除了包含所述检测控制信息字段之外还包含其他字段；
    所述其他字段至少包括：
    NextHeader字段，用于指示是否携带扩展数据类型，当为第一值时表示未携带扩展数据类型，当为第二值时表示携带扩展数据类型；
    扩展数据类型TLVs字段：用于在所述NextHeader字段为第二值时指示携带扩展数据；所述扩展数据至少包括：业务报文经由的节点的标识。
  9. 根据权利要求1所述的方法，其特征在于，所述第二报文头包括：IPv6扩展头；
    所述第二随流检测选项为所述IPv6扩展头中目的选项扩展头DOH的一个选项。
  10. 一种电子设备，其特征在于，该电子设备包括：处理器和机器可读存储介质；
    所述机器可读存储介质存储有能够被所述处理器执行的机器可执行指令；
    所述处理器用于执行机器可执行指令，以实现权利要求1-9任一项的方法步骤。
PCT/CN2021/082981 2021-03-25 2021-03-25 随流检测方法和电子设备 WO2022198560A1 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US18/001,865 US20230231804A1 (en) 2021-03-25 2021-03-25 In-situ flow detection method and electronic device
JP2022579791A JP7446489B2 (ja) 2021-03-25 2021-03-25 インサイチュフロー検出方法及び電子デバイス
EP21932187.4A EP4152658A4 (en) 2021-03-25 2021-03-25 IN SITU OAM PROCESS AND ELECTRONIC DEVICE
PCT/CN2021/082981 WO2022198560A1 (zh) 2021-03-25 2021-03-25 随流检测方法和电子设备
CN202180000608.2A CN115280745B (zh) 2021-03-25 2021-03-25 随流检测方法和电子设备
KR1020227042506A KR20230005369A (ko) 2021-03-25 2021-03-25 Ioam 방법 및 전자 기기

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2021/082981 WO2022198560A1 (zh) 2021-03-25 2021-03-25 随流检测方法和电子设备

Publications (1)

Publication Number Publication Date
WO2022198560A1 true WO2022198560A1 (zh) 2022-09-29

Family

ID=83395220

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/082981 WO2022198560A1 (zh) 2021-03-25 2021-03-25 随流检测方法和电子设备

Country Status (6)

Country Link
US (1) US20230231804A1 (zh)
EP (1) EP4152658A4 (zh)
JP (1) JP7446489B2 (zh)
KR (1) KR20230005369A (zh)
CN (1) CN115280745B (zh)
WO (1) WO2022198560A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115665006B (zh) * 2022-12-21 2023-03-28 新华三信息技术有限公司 一种随流检测方法及装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019089494A1 (en) * 2017-11-04 2019-05-09 Cisco Technology, Inc. In-band metadata export and removal at intermediate nodes
CN111277426A (zh) * 2018-12-05 2020-06-12 中兴通讯股份有限公司 一种ioam信息的处理方法和装置
CN111953604A (zh) * 2019-05-17 2020-11-17 华为技术有限公司 一种为业务流提供业务服务的方法和装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4744429B2 (ja) 2006-12-29 2011-08-10 Ｋｄｄｉ株式会社 拡張された保守ドメインレベル管理方法、通信装置、プログラム及びデータ構造
CN108737269B (zh) 2017-04-13 2021-11-26 中兴通讯股份有限公司 一种封装方法、装置和节点
US10812315B2 (en) * 2018-06-07 2020-10-20 Cisco Technology, Inc. Cross-domain network assurance
US10693777B2 (en) * 2018-06-26 2020-06-23 Cisco Technology, Inc. In-situ operations, administration, and maintenance (iOAM) for software defined architectures (SDAs)
US10931542B2 (en) * 2018-08-10 2021-02-23 Futurewei Technologies, Inc. Network embedded real time service level objective validation
CN111147383B (zh) * 2018-11-02 2021-06-29 华为技术有限公司 报文转发的方法、发送报文的装置和接收报文的装置
CN113315645A (zh) * 2020-02-27 2021-08-27 华为技术有限公司 配置性能探测指示信息的方法及相关设备
CN113382437A (zh) * 2020-03-10 2021-09-10 华为技术有限公司 一种随流检测方法及装置
CN113556259B (zh) * 2020-04-24 2024-04-12 华为技术有限公司 一种基于随流检测的报文处理方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019089494A1 (en) * 2017-11-04 2019-05-09 Cisco Technology, Inc. In-band metadata export and removal at intermediate nodes
CN111277426A (zh) * 2018-12-05 2020-06-12 中兴通讯股份有限公司 一种ioam信息的处理方法和装置
CN111953604A (zh) * 2019-05-17 2020-11-17 华为技术有限公司 一种为业务流提供业务服务的方法和装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Y. WANG T. ZHOU M. LIU HUAWEI R. PANG CHINA UNICOM H. CHEN CHINA TELECOM: "BGP-LS Extensions for In-situ Flow Information Telemetry (IFIT) Capability Advertisement; draft-wang-idr-bgpls-extensions-ifit-00.txt", BGP-LS EXTENSIONS FOR IN-SITU FLOW INFORMATION TELEMETRY (IFIT) CAPABILITY ADVERTISEMENT; DRAFT-WANG-IDR-BGPLS-EXTENSIONS-IFIT-00.TXT; INTERNET-DRAFT: INTER-DOMAIN ROUTING WORKING GROUP, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, IN, no. 00, 13 July 2020 (2020-07-13), Internet Society (ISOC) 4, rue des Falaises CH- 1205 Geneva, Switzerland , pages 1 - 9, XP015140834 *

Also Published As

Publication number Publication date
EP4152658A1 (en) 2023-03-22
KR20230005369A (ko) 2023-01-09
JP2023531987A (ja) 2023-07-26
CN115280745B (zh) 2023-05-26
JP7446489B2 (ja) 2024-03-08
US20230231804A1 (en) 2023-07-20
EP4152658A4 (en) 2023-05-03
CN115280745A (zh) 2022-11-01

Similar Documents

Publication Publication Date Title
US20210359939A1 (en) Packet processing method and network apparatus
US11979322B2 (en) Method and apparatus for providing service for traffic flow
US9843504B2 (en) Extending OpenFlow to support packet encapsulation for transport over software-defined networks
CN113207192B (zh) 一种报文转发方法及装置
WO2017124709A1 (zh) 流量工程隧道建立方法和装置
US9641420B1 (en) Methods and apparatus for assessing the quality of a data path including both layer-2 and layer-3 devices
WO2022078293A1 (zh) 组播业务流的检测方法及相关装置
US11882021B2 (en) Packet forwarding method, apparatus and system, network device and storage medium
WO2021190009A1 (zh) 性能测量方法、装置、设备和存储介质
CN112491718A (zh) 报文头的处理方法及装置、存储介质、电子装置
CN111614556A (zh) 一种基于bier的双向转发检测会话创建方法及相关设备
CN107968751A (zh) 一种信息处理方法及装置
WO2021227746A1 (zh) 发送和转发报文的方法、头节点、转发节点、存储介质
WO2022198560A1 (zh) 随流检测方法和电子设备
CN116939035A (zh) 数据处理方法、装置、电子设备以及存储介质
CN115208781A (zh) 检测报文的传输方法、装置及系统
WO2023125563A1 (zh) 路由信息的编辑方法、装置、存储介质及电子装置
CN114697408B (zh) 一种隧道报文的处理方法和装置
WO2023078144A1 (zh) 报文处理方法、装置及系统
WO2023184218A1 (zh) 通过bgp下发随流检测配置的方法及装置
US20230327983A1 (en) Performance measurement in a segment routing network
EP4156641A1 (en) Route notification method and electronic device
CN111193671B (zh) 报文处理方法、装置及可读存储介质
EP4336794A1 (en) Cross-autonomous system (as) multicast forwarding method and apparatus
CN110493134B (zh) 一种公网地址获取方法和装置

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 20227042506

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2021932187

Country of ref document: EP

Effective date: 20221212

ENP Entry into the national phase

Ref document number: 2022579791

Country of ref document: JP

Kind code of ref document: A

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

Ref document number: 21932187

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE