Patent Description:
A multi-protocol label switching transport profile (English: Multi Protocol Label Switching-Transport Profile, MPLS-TP for short) is a strict subset of MPLS. To adapt to a requirement of a transport network, some features that are not applicable to a transport network scenario and that are of MPLS are excluded, and a connection-oriented transmission technology that integrates MPLS packet switching and a transport network feature is used. OAM mainly includes three aspects: fault management (English: Fault Management), performance monitoring (English: Performance Monitoring), and protection switching (English: Protection Switching), can reflect a running status of a network, and is a most important network management means of an operator. An MPLS-TP OAM mechanism learns from and reuses the Y <NUM> standard, and mainly includes OAM functions at a label switched path (English: Label Switched Path, LSP for short) layer, a pseudo wire (English: Pseudo Wire, PW for short) layer, a section (English: Section, Sec for short) layer, and a ring (English: Ring) layer.

Currently, in an IP mode of MPLS-TP OAM, an existing network device identifier and an existing path identifier are used to respectively identify a sender network device and a to-be-detected path, and a maintenance entity group (English: Maintenance Entity Group, MEG for short) identifier and a maintenance entity group end point (English: Maintenance Entity Group End Point, MEP for short) identifier do not need to be additionally configured on the network device, so that fault management, performance monitoring, and protection switching can be implemented, which greatly reduces configuration costs and improves detection efficiency. Therefore, MPLS-TP OAM is favored by many carriers.

However, the IP mode of MPLS-TP OAM is applicable only to internet protocol version <NUM> (English: Internet Protocol version <NUM>, IPv4 for short), and a field that is in an OAM packet and that is used to carry an identifier of the network device is only <NUM>-bit space corresponding to IPv4. With evolution from IPv4 to internet protocol version <NUM> (English: Internet Protocol version <NUM>, IPv6 for short), to urgently resolve a problem that IPv6 cannot be applied in an MPLS-TP OAM scenario, an MPLS-TP OAM mechanism that can be applied to IPv4 and IPv6 is provided. <CIT> discloses methods for scalable and rapid Ethernet fault detection mechanisms which eliminate the requirement to contiguously send heartbeat frames at regular intervals to detect connectivity faults for each Ethernet Path. <NPL> discloses the application of a generic YANG data model to various network OAM technologies, enhancing protocol interoperability.

Based on this, embodiments of this application provide OAM packet processing methods, devices, a computer-readable storage medium and a system to expand an application scope based on advantages of MPLS-TP OAM, so that IPv4 and IPv6 are applicable, an MPLS-TP OAM mechanism is improved, and better use experience is provided for an operator. The invention is so defined by the appended set of claims.

The following describes technical solutions of embodiments in this application with reference to accompanying drawings. A network architecture and a service scenario described in embodiments of this application are intended to describe the technical solutions in embodiments of this application more clearly, and do not constitute a limitation on the technical solutions provided in embodiments of this application. A person of ordinary skill in the art may know that with evolution of the network architecture and emergence of new service scenarios, the technical solutions provided in embodiments of this application are also applicable to similar technical problems.

Ordinal numbers such as "<NUM>", "<NUM>", "<NUM>", "first", "second", and "third" in this application are used to distinguish between a plurality of objects, but are not intended to limit a sequence of the plurality of objects.

It should be understood that "A and/or B" mentioned in this application includes the following cases: Only A is included, only B is included, or both A and B are included.

Based on an actual requirement of an operator network, management work of the network usually includes three categories: operation (English: Operation), administration (English: Administration), and maintenance (English: Maintenance), OAM for short. MPLS-TP OAM is an OAM mechanism defined in MPLS-TP. MPLS-TP OAM is compatible with MPLS OAM functions and is correspondingly extended for transport network characteristics. Therefore, MPLS-TP OAM is widely concerned by carriers.

Currently, there are two modes of MPLS-TP OAM: an international telecommunication union carrier code (English: International Telecommunication Union Carrier Code, ICC for short) mode and an internet protocol (English: Internet Protocol, IP for short) mode. The ICC mode is a mode defined in Y. In the ICC mode, a maintenance entity group end point identifier (English: Maintenance Entity Group End Point Identifier, MEP ID for short) and a maintenance entity group identifier (English: Maintenance Entity Group Identifier, MEG ID for short) need to be configured on a network device, and the MEP ID and the MEG ID is carried in an OAM packet, to manage a network. In the IP mode, an MEP ID and an MEG ID do not need to be additionally configured on a network device, but an identifier of the network device and an identifier of a path are carried in an OAM packet, to manage a network.

The OAM packet may include, for example, a continuity check message (English: Continuity Check Message, CCM for short), a loss measurement message (English: Loss Measurement Message, LMM for short), and a loss measurement reply (English: Loss Measurement Reply, LMR for short) packet.

A CCM of MPLS-TP OAM is used as an example. A format of a protocol data unit (English: Protocol Data Unit, PDU for short) of the CCM in an ICC mode is shown in <FIG>. The CCM PDU includes: an MEG level (English: Maintenance Entity Group Level, MEL for short) field, a version (English: Version) field, an operation code (English: Operation Code, OpCode for short) field, a remote defect indication (English: Remote Defect Indication, RDI for short) field, a reserved (English: Reserved) field, a period (English: Period) field, a type length value (English: Type Length Value, TLV for short) offset (English: Offset) field, a sequence number (English: Sequence Number) field, an MEP ID field, an MEG ID (also referred to as MAID) field, a count of data frames sent at a local end TxFCf field, a count of data frames received at the local end RxFCb field, a count of data frames sent at a peer end TxFCb field, a reserved field, and an end TLV (English: End TLV) field. A value of the MEL field is used to identify a level of the CCM PDU, and is an integer ranging from <NUM> to <NUM>. A value of the version field is used to identify a used protocol version. For MPLS-TP OAM, an applicable protocol version is Y <NUM>, and a value that is of the version field and that corresponds to the protocol version is <NUM>. A value of the OpCode field is used to identify a type of the OAM PDU, to identify content of the OAM PDU based on the type of the OAM PDU. For the CCM, a value of the OpCode is <NUM>. A value of the RDI field is used to identify whether a transmit end MEP detects a fault. When the value of the RDI field is <NUM>, it indicates that the transmit end MEP detects a fault. When the value of the RDI field is <NUM>, it indicates that the transmit end MEP does not detect a fault. A value of the period field is used to identify a period of sending a CCM. For example, when the value of the period field is <NUM>, it indicates that the period of sending the CCM is <NUM> milliseconds (that is, <NUM> frames of CCMs are sent per second). When the value of the period field is <NUM>, indicates that the period of sending the CCM is <NUM> milliseconds (that is, <NUM> frames of CCMs are sent per second). A value of the TLV offset field is used to indicate an offset of a first TLV in the OAM PDU relative to the TLV offset field, and a specific value is related to a type of the OAM PDU. For example, when TLV Offset=<NUM>, it indicates that the first TLV follows the TLV offset field, and the value of the TLV offset field in the CCM is 0x46. A value of the sequence number field is used to identify a sequence number. For MPLS-TP OAM, a value of the sequence number field is <NUM>. A length of the MEP ID field is <NUM> bits, and a value of the MEP ID field is used to uniquely identify, in the MEG ID field, an MEP of sending a CCM frame, and is usually set to the least significant <NUM> bits. A length of the MEP ID field is <NUM> bits, and a value of the MEG ID field is used to globally uniquely identify an MEG to which the MEP of sending the CCM frame belongs. A value of the TxFCf field is used to indicate a count value of a non-exceeding data frame counter sent by a carrier MEP to a peer MEP during transmission of a CCM frame. A value of the RxFCb field is used to indicate a count value of a non-exceeding data frame counter received by a peer MEP during transmission of a CCM frame. When dual-ended performance statistics are not performed, the value of the RxFCb field is <NUM>. A value of the TxFCb field is used to indicate a count value of a non-exceeding data frame counter sent by a peer MEP during transmission of a CCM frame. When dual-ended performance statistics are not performed, the values of the TxFCf field, the RxFCb field, and the TxFCb field are all <NUM>. A value of the end TLV field is used to identify a quantity of all-zero bytes included in the CCM PDU.

A format of the CCM PDU in the IP mode is shown in <FIG>. The CCM PDU includes: an MEL field, a version field, an OpCode field, an RDI field, a reserved field, a period field, a TLV offset field, a sequence number field, a type field, a reserved/PW type field, a network device identifier field, a path identifier field, a reserved field, a TxFCf field, an RxFCb field, a TxFCb field, a reserved field, and an end TLV field. For related descriptions of the MEL field, the version field, the OpCode field, the RDI field, the period field, the TLV offset field, the sequence number field, the TxFCf field, the RxFCb field, the TxFCb field, and the end TLV field, refer to descriptions in <FIG>. A value of the type field is used to indicate a type of a path detected by the CCM. For example, if the value of the type field is <NUM>, it indicates that the CCM detects a label switched path (English: Label Switched Path, LSP for short). A value of the reserved/PW type field is used to indicate a service type. For example, when the value of the reserved/PW type field is 0x0000, the value of the reserved/PW type field is used to indicate a path type indicated by the value of the type field. For example, when Type=<NUM> and Reserved/PW Type=0x0000, it indicates that the CCM detects an LSP. When values of the reserved/PW type field is 0x0002 to 0x001B, 0x1001, and 0x1002, the values are respectively used to indicate different pseudo wire (English: Pseudo Wire, PW for short) service types. A value of the network device identifier field is used to uniquely identify a network device that sends the CCM. For example, assuming that the network device is a label switching router (English: Label Switching Router, LSR for short), a value of the network device identifier field may be an LSR ID. A value of the path identifier field is used to uniquely identify a to-be-detected path. For example, assuming that the network device is an LSR, a value of the path identifier field may be specifically an identifier of a tunnel in which the LSR is located.

It should be noted that an MPLS-TP OAM operation is performed based on a maintenance entity (English: Maintenance Entity, ME for short). One ME may be understood as two endpoints of a path, that is, a pair of MEPs and an intermediate MEG intermediate point (English: Maintenance Entity Group Intermediate Point, MIP for short). An OAM function mainly runs between the two MEPs. One or more MEs that belong to a same transmission path form one MEG. The MEP has a capability of initiating and terminating an OAM packet, and can perform fault management and performance monitoring. The MIP is an intermediate point of the MEG, can forward an OAM packet, and respond to a part of the OAM packet, but cannot initiate the OAM packet.

In an ICC mode, to uniquely identify a sender network device and a transmission path of OAM detection, an MEP ID and an MEG ID are configured on the network device, and the MEP ID and MEG ID are carried in the OAM packet. In this way, if there are a large quantity of network devices on a network, a large quantity of configurations need to be performed. In addition, to ensure effectiveness of OAM detection, configuring repeated MEP IDs and MEG IDs on a large quantity of network devices further need to be avoided, which is not simple and convenient for a user. In the IP mode, known information on the network device, that is, an identifier of the network device and an identifier of a path, is used to replace functions of the MEP ID and the MEG ID in the OAM packet, that is, uniquely identify the sender network device and the transmission path of OAM detection. Therefore, in the IP mode of MPLS-TP OAM, the MEP ID and the MEG ID do not need to be configured on the network device, so that a configuration workload of a user can be reduced and repeated configuration does not need to be considered. Therefore, the IP mode has significant advantages and is favored by users.

Currently, an OAM packet in the IP mode of MPLS-TP OAM is shown in <FIG>. A length of a network device identifier field is <NUM> bits, and the field is applicable only to carrying an IP address of a network device in an internet protocol version <NUM> (English: Internet Protocol version <NUM>, IPv4 for short) scenario, and cannot be applied to carrying a <NUM>-bit IP address of a network device in an internet protocol version <NUM> (English: Internet Protocol version <NUM>, IPv6 for short) scenario. Therefore, the IP mode of MPLS-TP OAM cannot meet requirements of an IPv6 network and a network smoothly evolving from IPv4 to IPv6.

Based on this, an embodiment of this application provides an OAM packet processing method. An OAM packet generated by a sender network device includes indication information, and the indication information is used to indicate a type of an identifier of the sender network device, that is, indicate whether the identifier of the sender network device is an IPv4 address or an IPv6 address. When the indication information carried in the OAM packet indicates that an IP address of the sender network device is the IPv4 address, the identifier that is of the first network device and that is included in the OAM packet is the IPv4 address of the first network device. When the indication information carried in the OAM packet indicates that an IP address of the sender network device is the IPv6 address, the identifier that is of the first network device and that is included in the OAM packet is the IPv6 address of the first network device. In this way, a second network device that receives the OAM packet can determine, based on the indication information, the type of the identifier that is of the sender network device and that is carried in the OAM packet, and accurately read the identifier of the sender network device from the OAM packet. Therefore, a user can perform MPLS-TP OAM to reduce a configuration workload, and can also implement MPLS-TP OAM in a plurality of scenarios such as an IPv4 network, an IPv6 network, and a network including IPv4 and IPv6, to expand an application scope of MPLS-TP OAM, and improve use experience of the user.

It should be noted that the OAM packet in this embodiment of this application may be a packet corresponding to any mode of MPLS-TP OAM. For example, if the OAM packet is a packet corresponding to an ICC mode of MPLS-TP OAM, the indication information in the OAM packet may also be used to indicate a type of an identifier (that is, an MEP ID) of the first network device, and is specifically used to indicate whether the OAM packet is an IPv4 network packet or an IPv6 network packet. In the IP mode of MPLS-TP OAM, the MEP ID and the MEG ID do not need to be configured on the network device, so that configuration resources can be saved. Therefore, the IP mode provides better user experience. Based on this, in this embodiment of this application, the OAM packet corresponding to the IP mode of MPLS-TP OAM is used as an example for related description.

For example, the CCM is still used as an example. In this embodiment of this application, a value of the type field is set to indicate an MEG type detected by the CCM and an applicable IP network. For example, values <NUM> to <NUM> of the type field respectively indicate that the CCM detects MEGs of an LSP type, a PW type, a section (English: Section) type, and a ring (English: Ring) type, and is applicable to an IPv4 network; and values <NUM> to <NUM> of the type field respectively indicate that the CCM detects MEGs of an LSP type, a PW type, a section type, and a ring type, and is applicable to an IPv6 network.

In an example, a format of a CCM PDU in a CCM generated by a network device in an IPv4 network is shown in <FIG>. In addition to the MEL field, the version field, the OpCode field, the RDI field, the reserved field, the period field, the TLV offset field, the sequence number field, the TxFCf field, the RxFCb field, the TxFCb field, the reserved field, and the end TLV field, the CCM PDU further includes a type field, a reserved field, a network device identifier field, a path identifier field, and a reserved field. If a value of the type field is <NUM>, it indicates that the CCM detects an MEG of an LSP type and is applicable to an IPv4 network. A value of the network device identifier field is an LSR ID, and the LSR ID may be specifically a <NUM>-bit IPv4 address of an LSR. A value of the path identifier field is an identifier of a tunnel (English: Tunnel) in which the LSR is located.

In another example, a format of a CCM PDU in a CCM generated by a network device in an IPv6 network is shown in <FIG>. In the CCM PDU, if a value of the type field is <NUM>, it indicates that the CCM detects an MEG of a PW type and is applicable to the IPv6 network; a value of the network device identifier field is an LSR ID, and the LSR ID may be specifically a <NUM>-bit IPv6 address of an LSR; and a value of the path identifier field is an identifier of a virtual channel (English: Virtual Channel, VC for short) of a PW.

In this way, the receiver network device can accurately read the identifier of the sender network device based on the indication information in the received OAM packet, to effectively implement an OAM function.

It should be noted that the network device in this embodiment of this application is any network device that can implement an OAM function, for example, may be a packet transport network (English: Packet Transport Network, PTN for short) device, a switch, or a router. This is not specifically limited in this embodiment of this application.

It may be understood that, the scenario is merely a scenario example provided in embodiments of this application, but embodiments of this application are not limited to the scenario.

With reference to the accompanying drawings, the following describes in detail a specific implementation of an OAM packet processing method in embodiments of this application by using embodiments.

An embodiment of this application provides an OAM packet processing method <NUM>. An IP mode of MPLS-TP OAM is used as an example. The method <NUM> is applicable to an IPv4 network, an IPv6 network, and a network including both IPv4 and IPv6. <FIG> is a schematic flowchart of an OAM packet processing method <NUM> according to an embodiment of this application. Refer to <FIG>. The method <NUM> may include, for example, the following steps.

S301: A network device <NUM> generates an OAM packet, where the OAM packet includes indication information and an identifier <NUM> of the network device <NUM>, and the indication information is used to indicate a type of the identifier <NUM> of the network device <NUM>.

The network device <NUM> is an MEP that initiates an OAM packet in an MEG, and an MEP that receives and terminates the OAM packet in the MEG is a network device <NUM>. The OAM packet is specifically a packet corresponding to an IP mode of MPLS-TP OAM.

The OAM packet includes an identifier <NUM> of a network device <NUM> and a path identifier <NUM>, which are respectively used to notify a network device <NUM> that a network device that initiates OAM detection is the network device <NUM> and a path of OAM detection is a path <NUM>, to ensure that effective OAM detection can be implemented based on the OAM packet. For example, the network device <NUM> is an LSR. The identifier <NUM> of the network device <NUM> may be an LSR ID, and the LSR ID is used to uniquely identify an LSR. The LSR ID may be, for example, an IP address of the LSR. If the LSR belongs to an IPv4 network, the LSR ID is an IPv4 address of the LSR. If the LSR belongs to an IPv6 network, the LSR ID is an IPv6 address of the LSR.

If the identifier <NUM> of the network device <NUM> is an IPv4 address, a field used to carry the identifier <NUM> of the network device <NUM> occupies at least <NUM>-bit space in the OAM packet; or if the identifier <NUM> of the network device <NUM> is an IPv6 address, a field used to carry the identifier <NUM> of the network device <NUM> occupies at least <NUM>-bit space in the OAM packet, to expand an application scope of MPLS-TP OAM, so that an OAM function is applicable to a plurality of scenarios such as an IPv4 network, an IPv6 network, and a network including an IPv4 and an IPv6. To enable the receiver network device to effectively obtain the identifier <NUM> of the network device <NUM>, the OAM packet also carries indication information. The indication information is used to indicate a type of the identifier <NUM> of the network device <NUM>, that is, the indication information may be used to indicate whether the OAM packet is an IPv4 network packet or an IPv6 network packet, or the indication information may indicate whether the identifier <NUM> of the network device <NUM> is an IPv6 address or an IPv4 address. In this way, the receiver network device can accurately obtain the identifier <NUM> of the network device <NUM> from the OAM packet based on the indication information, to implement effective OAM detection.

In an example, the indication information may be carried in a type field, and the type field is further used to indicate a type of an MEG. For example, if a value of the type field is <NUM>, it indicates that the OAM detects an MEG of an LSP type, and the identifier <NUM> of the network device <NUM> initiating OAM detection is an IPv4 address; if a value of the type field is <NUM>, it indicates that the OAM detects an MEG of a PW type, and the identifier <NUM> of the network device <NUM> initiating OAM detection is an IPv4 address; if a value of the type field is <NUM>, it indicates that the OAM detects an MEG of a section type, and the identifier <NUM> of the network device <NUM> initiating OAM detection is an IPv4 address; if a value of the type field is <NUM>, it indicates that the OAM detects an MEG of a ring type, and the identifier <NUM> of the network device <NUM> initiating OAM detection is an IPv4 address; if a value of the type field is <NUM>, it indicates that the OAM detects an MEG of an LSP type, and the identifier <NUM> of the network device <NUM> initiating OAM detection is an IPv6 address; if a value of the type field is <NUM>, it indicates that the OAM detects an MEG of a PW type, and the identifier <NUM> of the network device <NUM> initiating OAM detection is an IPv6 address; if a value of the type field is <NUM>, it indicates that the OAM detects an MEG of a section type, and the identifier <NUM> of the network device <NUM> initiating OAM detection is an IPv6 address; or if a value of the type field is <NUM>, it indicates that the OAM detects an MEG of a ring type, and the identifier <NUM> of the network device <NUM> initiating OAM detection is an IPv6 address. Based on this, when the value of the type field is any value in <NUM> to <NUM>, it may indicate that the type of the identifier <NUM> of the network device <NUM> is the IPv4 address; and when the value of the type field is any value in <NUM> to <NUM>, it may indicate that the type of the identifier <NUM> of the network device <NUM> is the IPv6 address.

In another example, the indication information may alternatively be carried in a reserved field. For example, at least one unoccupied bit in the reserved field is used to carry the indication information. It should be noted that the reserved field is a space of <NUM> bits (a zeroth bit to a fifteenth bit), and currently an eighth bit and a twelfth bit are occupied to represent a service type of a PW. Based on this, the indication information may be specifically at least one of an eighth bit, a ninth bit, a tenth bit, an eleventh bit, a thirteenth bit, a fourteenth bit, and a fifteenth bit. When the at least one bit is a first value, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address; or when the at least one bit is a second value, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. In a case, for example, an eighth bit of the reserved field carries the indication information. The first value is <NUM>, and the second value is <NUM>. In this case, when a value of the eighth bit of the reserved field is <NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address; or when a value of the eighth bit of the reserved field is <NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. In another case, for example, the eighth bit and the ninth bit of the reserved field carry the indication information. The first value is <NUM>, and the second value is <NUM>. In this case, when values of the eighth bit and the ninth bit of the reserved field are <NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address; or when values of the eighth bit and the ninth bit of the reserved field are <NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. In still another case, for example, the eighth bit to the eleventh bit of the reserved field carry the indication information. The first value is <NUM>, and the second value is <NUM>. In this case, when the eighth bit to the eleventh bit of the reserved field are <NUM> (a value of <NUM>), it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address; or when the eighth bit to the eleventh bit of the reserved field are <NUM> (a value of <NUM>), it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address.

In a case in which the type field carries the indication information, a format of the OAM PDU is described by using an example in which a path type detected in the CCM is an LSP type, a section type, a PW type, or a ring type.

When the detected path type is the LSP type, if the identifier <NUM> of the network device <NUM> is an IPv4 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Type field=<NUM>, it indicates that the OAM detects an MEG of the LSP type and the type of the identifier <NUM> of the network device <NUM> is an IPv4 address. Field (represented as an LSR ID in the figure) of the identifier <NUM> of the network device <NUM>=<NUM>-bit IPv4 address of the network device <NUM>. Field (represented as an LSP ID in the figure) of the path identifier <NUM>=Identifier of a tunnel in which the network device <NUM> is located. If the identifier <NUM> of the network device <NUM> is an IPv6 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Type field=<NUM>, it indicates that the OAM detects an MEG of the LSP type and the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. LSR ID=<NUM>-bit IPv6 address of the network device <NUM>. Field (represented as an LSP ID in the figure) of the path identifier <NUM>=Identifier of a tunnel in which the network device <NUM> is located.

When the detected path type is the PW type, if the identifier <NUM> of the network device <NUM> is an IPv4 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Type field=<NUM>, it indicates that the OAM detects an MEG of the PW type and the type of the identifier <NUM> of the network device <NUM> is an IPv4 address. Field (represented as an LSR ID in the figure) of the identifier <NUM> of the network device <NUM>=<NUM>-bit IPv4 address of the network device <NUM>. Field (represented as a PW VC ID in the figure) of the path identifier <NUM>=Identifier of a PW VC in which the network device <NUM> is located. If the identifier <NUM> of the network device <NUM> is an IPv6 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Type field=<NUM>, it indicates that the OAM detects an MEG of the PW type and the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. LSR ID=<NUM>-bit IPv6 address of the network device <NUM>. Field (represented as a PW VC ID in the figure) of the path identifier <NUM>=Identifier of a PW VC in which the network device <NUM> is located. The eighth bit and the twelfth bit of the reserved field are occupied to indicate a type of the PW VC (that is, indicate a service type of the PW). In this scenario, the reserved field is also referred to as a PW VC type field.

When the detected path type is the section type, if the identifier <NUM> of the network device <NUM> is an IPv4 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Type field=<NUM>, it indicates that the OAM detects an MEG of the section type and the type of the identifier <NUM> of the network device <NUM> is an IPv4 address. Field (represented as an LSR ID in the figure) of the identifier <NUM> of the network device <NUM>=<NUM>-bit IPv4 address of the network device <NUM>. Field (represented as a section ID in the figure) of the path identifier <NUM>=Identifier of a section to which the network device <NUM> belongs. If the identifier <NUM> of the network device <NUM> is an IPv6 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Type field=<NUM>, it indicates that the OAM detects an MEG of the section type and the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. LSR ID=<NUM>-bit IPv6 address of the network device <NUM>. Field (represented as a section ID in the figure) of the path identifier <NUM>=Identifier of a section to which the network device <NUM> belongs.

When the detected path type is the ring type, if the identifier <NUM> of the network device <NUM> is an IPv4 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Type field=<NUM>, it indicates that the OAM detects an MEG of the ring type and the type of the identifier <NUM> of the network device <NUM> is an IPv4 address. The identifier <NUM> of the network device <NUM> is represented by the identifier <NUM> (represented as a ring node ID in the figure) of the network device <NUM> and a direction in a ring, that is, the OAM PDU includes an <NUM>-bit direction (English: Direction) field and an <NUM>-bit ring node ID field. Field (represented as a ring ID in the figure) of the path identifier <NUM>=Identifier of a ring to which the network device <NUM> belongs. If the identifier <NUM> of the network device <NUM> is an IPv6 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Type field=<NUM>, it indicates that the OAM detects an MEG of the ring type and the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. The LSR ID is represented by a direction field and a ring node ID field. Field (represented as a ring ID in the figure) of the path identifier <NUM>=Identifier of a ring to which the network device <NUM> belongs.

In a case in which the reserved field carries the indication information, it is assumed that the eighth bit of the reserved field is used to carry the indication information. A format of the OAM PDU is described by using an example in which a path type detected in the CCM is an LSP type, a section type, a PW type, and a ring type.

When the detected path type is an LSP, if Type field=<NUM>, it indicates that the OAM detects an MEG of an LSP type. If the identifier <NUM> of the network device <NUM> is an IPv4 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Eighth bit of the reserved field=<NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address. Field (represented as an LSR ID in the figure) of the identifier <NUM> of the network device <NUM>=<NUM>-bit IPv4 address of the network device <NUM>. Field (represented as an LSP ID in the figure) of the path identifier <NUM>=Identifier of a tunnel in which the network device <NUM> is located. If the identifier <NUM> of the network device <NUM> is an IPv6 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Eighth bit of the reserved field=<NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. LSR ID=<NUM>-bit IPv6 address of the network device <NUM>. Field (represented as an LSP ID in the figure) of the path identifier <NUM>=Identifier of a tunnel in which the network device <NUM> is located.

When the detected path type is the PW type, if Type field=<NUM>, it indicates that the OAM detects an MEG of the PW type. If the identifier <NUM> of the network device <NUM> is an IPv4 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Eighth bit of the reserved field=<NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address. Field (represented as an LSR ID in the figure) of the identifier <NUM> of the network device <NUM>=<NUM>-bit IPv4 address of the network device <NUM>. Field (represented as a PW VC ID in the figure) of the path identifier <NUM>=Identifier of a PW VC in which the network device <NUM> is located. If the identifier <NUM> of the network device <NUM> is an IPv6 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Eighth bit of the reserved field=<NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. LSR ID=<NUM>-bit IPv6 address of the network device <NUM>. Field (represented as a PW VC ID in the figure) of the path identifier <NUM>=Identifier of a PW VC in which the network device <NUM> is located. The eighth bit and the twelfth bit of the reserved field are occupied to indicate a type of the PW VC (that is, indicate a service type of the PW). In this scenario, the reserved field is also referred to as a PW VC type field.

When the detected path type is a section type, if Type field=<NUM>, it indicates that the OAM detects an MEG of the section type. If the identifier <NUM> of the network device <NUM> is an IPv4 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Eighth bit of the reserved field=<NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address. Field (represented as an LSR ID in the figure) of the identifier <NUM> of the network device <NUM>=<NUM>-bit IPv4 address of the network device <NUM>. Field (represented as a section ID in the figure) of the path identifier <NUM>=Identifier of a section to which the network device <NUM> belongs. If the identifier <NUM> of the network device <NUM> is an IPv6 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Eighth bit of the reserved field=<NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. LSR ID=<NUM>-bit IPv6 address of the network device <NUM>. Field (represented as a section ID in the figure) of the path identifier <NUM>=Identifier of a section to which the network device <NUM> belongs.

When the detected path type is a ring type, if Type field=<NUM>, it indicates that the OAM detects an MEG of the ring type. If the identifier <NUM> of the network device <NUM> is an IPv4 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Eighth bit of the reserved field is <NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address. The identifier <NUM> of the network device <NUM> is represented by a direction field and a ring node ID field. Field (represented as a ring ID in the figure) of the path identifier <NUM>=Identifier of a ring to which the network device <NUM> belongs. If the identifier <NUM> of the network device <NUM> is an IPv6 address of the network device <NUM>, for details about the OAM PDU, reference is made to <FIG>. If Eighth bit of the reserved field=<NUM>, it indicates that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address. The LSR ID is represented by a direction field and a ring node ID field. Field (represented as a ring ID in the figure) of the path identifier <NUM>=Identifier of a ring to which the network device <NUM> belongs.

It should be noted that, in the foregoing example, the identifier <NUM> of the network device <NUM> occupies continuous space of the OAM PDU in the OAM packet, and a field that carries the identifier <NUM> of the network device <NUM> is adjacent to a field that carries the path identifier <NUM>. In some other possible implementations, in order not to extend a length of the field that carries the identifier <NUM> of the network device <NUM> in the current IP mode, when the network device <NUM> is a network device in an IPv6 network, the <NUM>-bit identifier <NUM> of the network device <NUM> may be segmented into the first <NUM> bits and the last <NUM> bits, where the first <NUM> bits are stored in the field that carries the identifier <NUM> of the network device <NUM> in the current IP mode, and the last <NUM> bits of the IPv6 address are stored in a reserved field after a field that carries the path identifier <NUM>. The scenario shown in <FIG> is used as an example. For example, for a format of the OAM PDU in this implementation, refer to <FIG>.

In this way, the network device <NUM> generates the OAM packet that carries the indication information, so that it is possible that an OAM mechanism is applicable to more extensive application scenarios.

S302: The network device <NUM> sends the OAM packet to the network device <NUM>.

S303: The network device <NUM> receives the OAM packet sent by the network device <NUM>.

In this embodiment of this application, an occasion, a rule, and a specific sending manner of sending the OAM packet by the network device <NUM> to the network device <NUM> are not limited.

S304: The network device <NUM> reads the identifier <NUM> of the network device <NUM> from the OAM packet based on the indication information.

In a specific implementation, after receiving the OAM packet, the network device <NUM> obtains the indication information from the OAM packet, and accurately reads the identifier <NUM> of the network device <NUM> from the OAM packet based on an indication of the indication information. In an example, when the indication information is used to indicate that the type of the identifier <NUM> of the network device <NUM> is an IPv6 address, S304 may be that the network device <NUM> reads the IPv6 address of the network device <NUM> from the OAM packet. In another example, when the indication information is used to indicate that the type of the identifier <NUM> of the network device <NUM> is an IPv4 address, S304 may be that the network device <NUM> reads the IPv4 address of the network device <NUM> from the OAM packet.

For example, it is assumed that a format of an OAM PDU in the OAM packet is shown in <FIG>, <FIG>, <FIG>, or <FIG>. S304 may specifically mean that the network device <NUM> parses the OAM packet to obtain a value of the type field, and determines, based on the value of the type field, that the type of the identifier <NUM> of the network device <NUM> that initiates the OAM packet is an IPv4 address. In this case, the network device <NUM> reads, from the OAM packet, <NUM>-bit information that is before the field used to carry the path identifier <NUM> and that is adjacent to the field, and uses the information as the identifier <NUM> of the network device <NUM>, that is, the IPv4 address of the network device <NUM>. It is assumed that a format of an OAM PDU in the OAM packet is shown in <FIG>, <FIG>, <FIG>, or <FIG>. S304 may specifically mean that the network device <NUM> parses the OAM packet to obtain a value of the type field, and determines, based on the value of the type field, that the type of the identifier <NUM> of the network device <NUM> that initiates the OAM packet is an IPv6 address. In this case, the network device <NUM> reads, from the OAM packet, <NUM>-bit information that is before the field used to carry the path identifier <NUM> and that is adjacent to the field, and uses the information as the identifier <NUM> of the network device <NUM>, that is, the IPv6 address of the network device <NUM>. In addition, it is assumed that a format of an OAM PDU in the OAM packet is shown in <FIG>. S304 may specifically mean that the network device <NUM> parses the OAM packet to obtain a value of the type field, and determines, based on the value of the type field, that the type of the identifier <NUM> of the network device <NUM> that initiates the OAM packet is an IPv6 address. In this case, the network device <NUM> reads, from the OAM packet, <NUM>-bit information that is before the field used to carry the path identifier <NUM> and that is adjacent to the field, and <NUM>-bit information that is after the field used to carry the path identifier <NUM> and that is adjacent to the field, and combines the <NUM>-bit information and the <NUM>-bit information to obtain the identifier <NUM> of the network device <NUM>, that is, the IPv6 address of the network device <NUM>.

For example, it is assumed that a format of an OAM PDU in the OAM packet is shown in <FIG>, <FIG>, <FIG>, or <FIG>. S304 may specifically mean that the network device <NUM> parses the OAM packet to obtain a value of the eighth bit of the reserved field, and determines, based on the value of the eighth bit of the reserved field, that the type of the identifier <NUM> of the network device <NUM> that initiates the OAM packet is an IPv4 address. In this case, the network device <NUM> reads, from the OAM packet, <NUM>-bit information that is after the reserved field and that is before the field used to carry the path identifier <NUM>, and uses the information as the identifier <NUM> of the network device <NUM>, that is, the IPv4 address of the network device <NUM>. It is assumed that a format of an OAM PDU in the OAM packet is shown in <FIG>, <FIG>, <FIG>, or <FIG>. S304 may specifically mean that the network device <NUM> parses the OAM packet to obtain a value of the eighth bit of the reserved field, and determines, based on the value of the eighth bit of the reserved field, that the type of the identifier <NUM> of the network device <NUM> that initiates the OAM packet is an IPv6 address. In this case, the network device <NUM> reads, from the OAM packet, <NUM>-bit information that is after the reserved field and that is before the field used to carry the path identifier <NUM>, and uses the information as the identifier <NUM> of the network device <NUM>, that is, the IPv6 address of the network device <NUM>.

It should be noted that in this embodiment of this application, an example in which the OAM packet is a CCM is used for description. Other OAM packets such as an LMM and an LMR packet are all applicable to the OAM packet processing method provided in this embodiment of this application. To be specific, the indication information used to indicate the type of the identifier of the network device is carried in the OAM packet, so that an OAM mechanism is applicable to more network scenarios. For specific implementations of all types of OAM packets, refer to related descriptions of the CCM packet. Details are not described again in this embodiment of this application.

It should be noted that the network device <NUM> may implement OAM detection on the MEG from the network device <NUM> to the network device <NUM> based on the received OAM packet. A specific detection principle and implementation are not improvement points in this embodiment of this application, and are not described in detail in this embodiment of this application.

It can be learned that, according to the method <NUM> provided in this embodiment of this application, the OAM packet generated by the sender network device includes the indication information, and the indication information is used to indicate the type of the identifier of the sender network device, that is, indicate whether the identifier of the sender network device is an IPv4 address or an IPv6 address. When the indication information carried in the OAM packet indicates that an IP address of the sender network device is the IPv4 address, the identifier that is of the sender network device and that is included in the OAM packet is the IPv4 address of the sender network device. When the indication information carried in the OAM packet indicates that an IP address of the sender network device is the IPv6 address, the identifier that is of the sender network device and that is included in the OAM packet is the IPv6 address of the sender network device. In this way, a receiver network device that receives the OAM packet can determine, based on the indication information, the type of the identifier that is of the sender network device and that is carried in the OAM packet, and accurately read the identifier of the sender network device from the OAM packet. Therefore, a user can perform MPLS-TP OAM to reduce a configuration workload, and can also implement MPLS-TP OAM in a plurality of scenarios such as an IPv4 network, an IPv6 network, and a network including IPv4 and IPv6, to expand an application scope of MPLS-TP OAM, and improve use experience of the user.

<FIG> is a schematic flowchart of an OAM packet processing method <NUM> according to an embodiment of this application. Refer to <FIG>. An IP mode of MPLS-TP OAM is used as an example. The method <NUM> is applicable to an IPv6 network. The method <NUM> may include, for example, the following steps.

S701: A network device <NUM> generates an OAM packet, where the OAM packet includes an IPv6 address of the network device <NUM>.

Because a type of an identifier of the network device <NUM> is the IPv6 address, an identifier <NUM> that is of the network device <NUM> and that is carried in the OAM packet needs to occupy <NUM>-bit space. To be applicable to an MPLS-TP OAM mechanism in an IPv6 network, the OAM packet generated by the network device <NUM> needs to include <NUM>-bit space used to carry the identifier <NUM> of the network device <NUM>.

In an example, a field that carries the identifier <NUM> of the network device <NUM> may be extended in the OAM packet, and is extended from <NUM> bits to <NUM> bits, to carry the IPv6 address of the network device <NUM>. The scenario corresponding to <FIG> is used as an example. For example, for an OAM PDU in the OAM packet generated based on the method <NUM>, refer to <FIG>.

In another example, in the OAM packet, a field that carries the identifier <NUM> of the network device <NUM> is not extended, but <NUM> bits of the reserved field after the field used to carry the path identifier <NUM> are used to carry the last <NUM> bits of the IPv6 address of the network device <NUM>, or <NUM> bits of the reserved field after the field used to carry the path identifier <NUM> are used to carry the IPv6 address of the network device <NUM>. The scenario corresponding to <FIG> is still used as an example. For example, for the OAM PDU in the OAM packet generated according to the method <NUM>, refer to <FIG> or <FIG>. In <FIG>, the field originally used to carry the identifier <NUM> of the network device <NUM> carries the first <NUM> bits of the IPv6 address of the network device <NUM>, and the reserved field carries the last <NUM> bits of the IPv6 address of the network device <NUM>. In <FIG>, a value of the field originally used to carry the identifier <NUM> of the network device <NUM> is not limited, and the reserved field carries <NUM> bits of the IPv6 address of the network device <NUM>.

It should be noted that the OAM packet may further include a path identifier <NUM>, used to indicate a path type of OAM detection. The path type may be, for example, an LSP type, a PW type, a section type, or a ring type. In this case, the path identifier <NUM> may be any one of the following identifiers: an LSP identifier, a section identifier, a PW identifier, or a ring identifier.

S702: The network device <NUM> sends the OAM packet to the network device <NUM>.

S703: The network device <NUM> receives the OAM packet sent by the network device <NUM>.

S704: The network device <NUM> reads the IPv6 address of the network device <NUM> from the OAM packet.

In a specific implementation, after receiving the OAM packet, the network device <NUM> reads the identifier <NUM> of the network device <NUM> from the OAM packet, that is, reads the <NUM>-bit IPv6 address of the network device <NUM> from the OAM packet.

In this embodiment, the OAM packet may further include indication information, which is used to indicate a type of the identifier of the network device <NUM>, and is specifically used to indicate whether the OAM packet is an IPv4 network packet or an IPv6 network packet. For a manner of carrying the indication information in the OAM packet, refer to related descriptions of the indication information in the embodiment shown in <FIG>.

It can be learned that, according to the method <NUM> provided in this embodiment of this application, the OAM packet generated by the sender network device includes the IPv6 address of the network device <NUM> that is used as the identifier <NUM> of the network device <NUM>. In this way, a receiver network device that receives the OAM packet can accurately read the identifier of the sender network device from the OAM packet. Therefore, a user can perform MPLS-TP OAM in an IP mode to reduce a configuration workload, and can also implement MPLS-TP OAM in an IPv6 network scenario to improve use experience of the user.

<FIG> is a schematic flowchart of an OAM packet processing method <NUM> according to an embodiment of this application. Refer to <FIG>. For an IP mode of MPLS-TP OAM, the method <NUM> is performed by a first network device. The method <NUM> may include, for example, the following steps.

S901: A first network device generates an OAM packet, where the OAM packet includes indication information and an identifier of the first network device, and the indication information is used to indicate a type of the identifier of the first network device.

S902: The first network device sends the OAM packet to a second network device.

The first network device may be the network device <NUM> in the method <NUM>, and the second network device is the network device <NUM> in the method <NUM>. For specific operations performed by the first network device, refer to the operations performed by the network device <NUM> in the method <NUM>. The OAM packet may be the OAM packet in the method <NUM>, the indication information may be the indication information in the method <NUM>, and the identifier of the first network device may be the identifier <NUM> of the network device <NUM> in the method <NUM>.

In an example, the indication information in the OAM packet is used to indicate that the type of the identifier of the first network device is an IPv6 address. This ensures that the method <NUM> is applicable to an IPv6 network.

In another example, the indication information in the OAM packet is used to indicate that the type of the identifier of the first network device is an IPv4 address. This ensures that the method <NUM> is applicable to an IPv4 network.

In some possible implementations, the OAM packet includes a type field used to indicate an MEG type, and the type field may be used to carry the indication information. In a specific implementation, if a value of the type field is a first value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv6 address; or if a value of the type field is a second value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv4 address.

In some other possible implementations, the OAM packet includes a reserved field, and at least one bit in the reserved field may be used to carry the indication information. In a specific implementation, if the at least one bit in the reserved field is a first value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv6 address; or if the at least one bit in the reserved field is a second value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv4 address.

In an example, the OAM packet may further include an identifier of a path from the first network device to the second network device. The identifier of the path may be any one of the following identifiers: a label switched path LSP identifier, a section Section identifier, a pseudo wire PW identifier, or a ring Ring identifier. Specifically, a field that is in the OAM packet and that is used to carry the identifier of the path may be adjacent to a field used to carry the identifier of the first network device. In this way, the receiver can accurately complete OAM detection based on the identifier of the path and the identifier of the first network device.

It should be noted that the OAM packet in this embodiment of this application is specifically a packet corresponding to an IP mode of MPLS-TP OAM.

It can be learned that, according to the method <NUM> provided in this embodiment of this application, the OAM packet generated by the first network device includes the indication information, and the indication information is used to indicate the type of the identifier of the first network device, that is, indicate whether the identifier of the first network device is an IPv4 address or an IPv6 address. When the indication information carried in the OAM packet indicates that an IP address of the first network device is the IPv4 address, the identifier that is of the first network device and that is included in the OAM packet is the IPv4 address of the first network device. When the indication information carried in the OAM packet indicates that an IP address of the first network device is the IPv6 address, the identifier that is of the first network device and that is included in the OAM packet is the IPv6 address of the first network device. In this way, it can be ensured that a receiver network device that receives the OAM packet determines, based on the indication information, the type of the identifier that is of the first network device and that is carried in the OAM packet, and accurately reads the identifier of the first network device from the OAM packet. Therefore, a user can perform MPLS-TP OAM in an IP mode to reduce a configuration workload, and can also implement MPLS-TP OAM in a plurality of scenarios such as an IPv4 network, an IPv6 network, and a network including IPv4 and IPv6, to expand an application scope of MPLS-TP OAM, and improve use experience of the user.

<FIG> is a schematic flowchart of an OAM packet processing method <NUM> according to an embodiment of this application. Refer to <FIG>. For an IP mode of MPLS-TP OAM, the method <NUM> is performed by a second network device. The method <NUM> may include, for example, the following steps.

S1001: A second network device receives an OAM packet sent by a first network device, where the OAM packet includes indication information and an identifier of the first network device, and the indication information is used to indicate a type of the identifier of the first network device.

S1002: The second network device reads the identifier of the first network device from the OAM packet based on the indication information.

The second network device may be the network device <NUM> in the method <NUM>, and the first network device is the network device <NUM> in the method <NUM>. For specific operations performed by the second network device, refer to the operations performed by the network device <NUM> in the method <NUM>. The OAM packet may be the OAM packet in the method <NUM>, the indication information may be the indication information in the method <NUM>, and the identifier of the first network device may be the identifier <NUM> of the network device <NUM> in the method <NUM>.

In an example, the indication information in the OAM packet may be used to indicate that the type of the identifier of the first network device is an IPv6 address. In this case, for example, S1002 may include: The second network device reads the IPv6 address of the first network device from the OAM packet. This ensures that the method <NUM> is applicable to an IPv6 network.

In another example, the indication information in the OAM packet is used to indicate that the type of the identifier of the first network device is an IPv4 address. In this case, for example, S1002 may include: The second network device reads the IPv4 address of the first network device from the OAM packet. This ensures that the method <NUM> is applicable to an IPv4 network.

In some possible implementations, the OAM packet includes a type field used to indicate a MEG type, and the type field may be used to carry the indication information. In a specific implementation, if a value of the type field is a first value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv6 address; or if a value of the type field is a second value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv4 address.

It can be learned that, according to the method <NUM> provided in this embodiment of this application, the OAM packet received by the second network device includes the indication information, and the indication information is used to indicate the type of the identifier of the first network device, that is, indicate whether the identifier of the first network device is an IPv4 address or an IPv6 address. In this way, the second network device can determine, based on the indication information, the type of the identifier that is of the first network device and that is carried in the OAM packet, and accurately read the identifier of the first network device from the OAM packet. Therefore, a user can perform MPLS-TP OAM in an IP mode to reduce a configuration workload, and can also implement MPLS-TP OAM in a plurality of scenarios such as an IPv4 network, an IPv6 network, and a network including IPv4 and IPv6, to expand an application scope of MPLS-TP OAM, and improve use experience of the user.

S1101: A first network device generates an OAM packet, where the OAM packet includes an IPv6 address of the first network device.

S1102: The first network device sends an OAM packet to a second network device.

The first network device may be the network device <NUM> in the method <NUM>, and the second network device is the network device <NUM> in the method <NUM>. For specific operations performed by the first network device, refer to the operations performed by the network device <NUM> in the method <NUM>. The OAM packet may be the OAM packet in the method <NUM>, and the IPv6 address of the first network device may be the IPv6 address of the network device <NUM> in the method <NUM>.

It can be learned that, according to the method <NUM> provided in this embodiment of this application, the OAM packet generated by the first network device includes the IPv6 address of the first network device that is used as the identifier of the first network device. In this way, after receiving the OAM packet, the second network device can accurately read the identifier of the first network device from the OAM packet. Therefore, a user can perform MPLS-TP OAM in an IP mode to reduce a configuration workload, and can also implement MPLS-TP OAM in an IPv6 network scenario to improve use experience of the user.

S1201: A second network device receives an OAM packet sent by a first network device, where the OAM packet includes an IPv6 address of the first network device.

S1202: The second network device reads the IPv6 address of the first network device from the OAM packet.

The second network device may be the network device <NUM> in the method <NUM>, and the first network device is the network device <NUM> in the method <NUM>. For specific operations performed by the second network device, refer to the operations performed by the network device <NUM> in the method <NUM>. The OAM packet may be the OAM packet in the method <NUM>, and the IPv6 address of the first network device may be the IPv6 address of the network device <NUM> in the method <NUM>.

It can be learned that, according to the method <NUM> provided in this embodiment of this application, the OAM packet received by the second network device includes the IPv6 address of the first network device, so that the second network device can accurately read the identifier of the first network device from the OAM packet. Therefore, a user can perform MPLS-TP OAM in an IP mode to reduce a configuration workload, and can also implement MPLS-TP OAM in an IPv6 network scenario to improve use experience of the user.

In addition, as shown in <FIG>, an embodiment of this application further provides a first communications apparatus <NUM>. The first communications apparatus <NUM> includes a processing unit <NUM> and a sending unit <NUM>. The processing unit <NUM> is configured to perform the processing operation performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the processing operation performed by the first network device in the embodiments shown in <FIG> and <FIG>. The sending unit <NUM> is configured to perform the sending operation performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the sending operation performed by the first network device in the embodiments shown in <FIG> and <FIG>. For example, the processing unit <NUM> may perform an operation in the embodiment in <FIG>: generating an OAM packet. For example, the sending unit <NUM> may perform an operation in the embodiment in <FIG>: sending the OAM packet to the network device <NUM>.

In addition, as shown in <FIG>, an embodiment of this application further provides a second communications apparatus <NUM>. The second communications apparatus <NUM> includes a receiving unit <NUM> and a processing unit <NUM>. The receiving unit <NUM> is configured to perform the receiving operation performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the receiving operation performed by the second network device in the embodiments shown in <FIG> and <FIG>. The processing unit <NUM> is configured to perform the processing operation performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the processing operation performed by the second network device in the embodiments shown in <FIG> and <FIG>. For example, the receiving unit <NUM> may perform an operation in the embodiment in <FIG>: receiving an OAM packet sent by the network device <NUM>. The processing unit <NUM> may perform an operation in the embodiment in <FIG>: reading an identifier <NUM> of the network device <NUM> from the OAM packet based on indication information.

In addition, as shown in <FIG>, an embodiment of this application further provides a first communications apparatus <NUM>. The first communications apparatus <NUM> includes a first communications interface <NUM>, a second communications interface <NUM>, and a processor <NUM>. The first communications interface <NUM> is configured to perform the receiving operation performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the receiving operation performed by the first network device in the embodiments shown in <FIG> and <FIG>. The second communications interface <NUM> is configured to perform the sending operation performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the sending operation performed by the first network device in the embodiments shown in <FIG> and <FIG>. The processor <NUM> is configured to perform an operation other than the receiving operation and the sending operation that is performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and an operation other than the receiving operation and the sending operation that is performed by the first network device in the embodiments shown in <FIG> and <FIG>. For example, the processor <NUM> may perform an operation in the embodiment in <FIG>: generating an OAM packet.

In addition, as shown in <FIG>, an embodiment of this application further provides a second communications apparatus <NUM>. The second communications apparatus <NUM> includes a first communications interface <NUM>, a second communications interface <NUM>, and a processor <NUM>. The first communications interface <NUM> is configured to perform the receiving operation performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the receiving operation performed by the second network device in the embodiments shown in <FIG> and <FIG>. The second communications interface <NUM> is configured to perform the sending operation performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the sending operation performed by the second network device in the embodiments shown in <FIG> and <FIG>. The processor <NUM> is configured to perform an operation other than the receiving operation and the sending operation that is performed by the network device <NUM> in the embodiments shown in <FIG> and <FIG> and an operation other than the receiving operation and the sending operation that is performed by the second network device in the embodiments shown in <FIG> and <FIG>. For example, the processor <NUM> may perform an operation in the embodiment in <FIG>: reading an identifier <NUM> of the network device <NUM> from the OAM packet based on indication information.

In addition, as shown in <FIG>, an embodiment of this application further provides a first communications apparatus <NUM>. The first communications apparatus <NUM> includes a memory <NUM> and a processor <NUM> communicating with the memory <NUM>. The memory <NUM> includes computer-readable instructions. The processor <NUM> is configured to execute the computer-readable instructions, so that the first communications apparatus <NUM> performs the method performed on a side of the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the method performed by the first network device in the embodiments shown in <FIG> and <FIG>.

In addition, as shown in <FIG>, an embodiment of this application further provides a second communications apparatus <NUM>. The second communications apparatus <NUM> includes a memory <NUM> and a processor <NUM> communicating with the memory <NUM>. The memory <NUM> includes computer-readable instructions. The processor <NUM> is configured to execute the computer-readable instructions, so that the second communications apparatus <NUM> performs the method performed on a side of the network device <NUM> in the embodiments shown in <FIG> and <FIG> and the method performed by the second network device in the embodiments shown in <FIG> and <FIG>.

It may be understood that, in the foregoing embodiment, the processor may be a central processing unit (English: central processing unit, CPU for short), a network processor (English: network processor, NP for short), or a combination of a CPU and an NP. Alternatively, the processor may be an application-specific integrated circuit (English: application-specific integrated circuit, ASIC for short), a programmable logic device (English: programmable logic device, PLD for short), or a combination thereof. The PLD may be a complex programmable logic device (English: complex programmable logic device, CPLD for short), a field-programmable gate array (English: field-programmable gate array, FPGA for short), generic array logic (English: generic array logic, GAL for short), or any combination thereof. The processor may be one processor, or may include a plurality of processors. The memory may include a volatile memory (English: volatile memory), for example, a random-access memory (English: random-access memory, RAM for short). Alternatively, the memory may include a non-volatile memory (English: non-volatile memory), for example, a read-only memory (English: read-only memory, ROM for short), a flash memory (English: flash memory), a hard disk drive (English: hard disk drive, HDD for short), or a solid-state drive (English: solid-state drive, SSD for short). Alternatively, the memory may include a combination of the foregoing memories. The memory may be one memory, or may include a plurality of memories. In a specific implementation, the memory stores computer-readable instructions, and the computer-readable instructions include a plurality of software modules, for example, a sending module, a processing module, and a receiving module. After executing each software module, the processor may perform a corresponding operation according to an indication of each software module. In this embodiment, an operation performed by a software module is actually an operation performed by the processor according to an indication of the software module. After executing the computer-readable instructions in the memory, the processor may perform, according to an indication of the computer-readable instructions, all operations that can be performed by each network node in OAM detection.

It may be understood that, in the foregoing embodiment, the second communications apparatus <NUM> in the first communications apparatus <NUM> may be specifically used as the sending unit <NUM> in the first communications apparatus <NUM> to implement data communication between the first network device and the second network device. The first communications interface <NUM> in the first communications apparatus <NUM> may be specifically used as the receiving unit in the first communications apparatus <NUM>, for example, may be configured to receive another OAM packet sent by an upstream network device. Similarly, the first communications interface <NUM> in the second communications apparatus <NUM> may be specifically used as the receiving unit <NUM> in the second communications apparatus <NUM> to implement data communication between the first network device and the second network device. The second communications interface <NUM> in the second communications apparatus <NUM> may be specifically used as the sending unit in the second communications apparatus <NUM> to implement data communication between the second network device and a downstream network device.

In addition, as shown in <FIG>, an embodiment of this application further provides a communications system <NUM>. The communications system <NUM> includes a first communications apparatus <NUM> and a second communications apparatus <NUM>. The first communications apparatus <NUM> may be specifically the first communications apparatus <NUM>, the first communications apparatus <NUM>, or the first communications apparatus <NUM>. The second communications apparatus <NUM> may be specifically the second communications apparatus <NUM>, the second communications apparatus <NUM>, or the second communications apparatus <NUM>.

It should be noted that each communications apparatus in the foregoing embodiments may be a network device configured to perform the foregoing method, or may be a board, a line card, a chip, or the like configured to perform the foregoing method.

In addition, an embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium stores instructions, and when the instructions are run on a computer, the computer is enabled to perform the OAM packet processing methods in the embodiments shown in <FIG>, <FIG>, and <FIG> to <FIG>.

In addition, an embodiment of this application further provides a computer program product, including a computer program or computer-readable instructions. When the computer program or the computer-readable instructions are run on a computer, the computer is enabled to perform the OAM packet processing methods in the embodiments shown in <FIG>, <FIG>, and <FIG> to <FIG>.

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

Claim 1:
A multi-protocol label switching transport profile MPLS-TP-based operation, administration, and maintenance OAM packet processing method (<NUM>), wherein the method comprises:
generating (S1101), by a first network device, an OAM packet, wherein the OAM packet comprises indication information and an identifier of the first network device, and the indication information is used to indicate a type of the identifier of the first network device; and
sending (S1102), by the first network device, the OAM packet to a second network device, the method being characterised in that the OAM packet comprises a type field used to indicate a maintenance entity group, MEG, type, and the type field is used to carry the indication information, wherein when a value of the type field is a first value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv6 address; or when a value of the type field is a second value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv4 address, or
in that the OAM packet comprises a reserved field, and the reserved field is used to carry the indication information, wherein when at least one bit in the reserved field is a first value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv6 address; or when at least one bit in the reserved field is a second value, the indication information is used to indicate that the type of the identifier of the first network device is the IPv4 address.