A method and device for terminating an OAM message in a domain

By determining the service type and creating MEP entries on the local device, and configuring the destination port of the MEP entries to the CPU port for processing OAM messages, the problem of unreliable termination of OAM messages is solved, and secure and reliable intra-domain termination and resource optimization of OAM messages are achieved.

CN122395046APending Publication Date: 2026-07-14FIBERHOME TELECOMMUNICATION TECHNOLOGIES CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
FIBERHOME TELECOMMUNICATION TECHNOLOGIES CO LTD
Filing Date
2026-04-30
Publication Date
2026-07-14

AI Technical Summary

Technical Problem

In cases of asymmetrical OAM configuration, OAM messages cannot be reliably terminated within the business domain, leading to network security risks and false alarms.

Method used

After the local device creates a service, it determines whether it is an end station node type. Based on the service protection type, it creates a corresponding number of maintenance endpoint MEP entries and configures the destination port of the MEP entry as the CPU port without processing it, so as to ensure that the OAM message is terminated within the service domain.

Benefits of technology

It achieves reliable termination of OAM messages within the business domain, avoiding network security risks and false alarms, while optimizing network resource utilization.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122395046A_ABST
    Figure CN122395046A_ABST
Patent Text Reader

Abstract

The application discloses an OAM message in-domain termination method and device, and relates to the technical field of communication. The OAM message in-domain termination method comprises the following steps: after a local device creates a service, it is judged whether the service is an end station node type; if the service is the end station node type, a corresponding number of maintenance end points (MEP) entries are created according to a service protection type; a destination port of the MEP entry is configured as a CPU port and is set to be not processed, so that when the local OAM is not created or fails to be created, OAM messages are terminated in the service domain. The application can ensure that OAM messages are reliably terminated in the service domain under the condition that OAM configuration is asymmetric.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to an OAM message domain termination method and apparatus. Background Technology

[0002] OAM (Operation, Administration and Maintenance) frames are generated within the telecommunications network. Therefore, regardless of whether OAM is configured on the device, the customer service access device must terminate OAM frames to ensure that OAM frames are not transmitted to the user. That is, OAM frames within the network are terminated on the device at the service boundary.

[0003] When intranet OAM frames cannot be reliably terminated at service boundary devices, several problems can arise. On the one hand, for encrypted services in government agencies and banks, the user side will set up security systems. If an unidentified message comes from the transmission channel, it will be considered an abnormal intrusion, affecting the continuity of encrypted services. On the other hand, for situations where there are multiple packet services on the transmission channel with the same CFMOAM (Connectivity Fault Management OAM) level, if an OAM message is not terminated within its own service domain and is matched and hit by OAM edge nodes in other service domains, false alarms may occur.

[0004] For VS layer and VP layer TPOAM (Transmission Pseudowire OAM) messages, because the message format carries a GAL tag, even if it is not terminated by an OAM edge node, its tag value cannot match the service characteristic value, and the message will not be forwarded to the outside domain. Therefore, the main focus should be on the reliable termination status of VC layer TPOAM messages and CFM OAM messages within the service domain.

[0005] However, currently, the industry generally lacks protective measures for this requirement. In cases of asymmetrical OAM configuration, it cannot be guaranteed that the TPOAM and CFM OAM messages generated by the device will terminate within the network and will not be transmitted to the user. Summary of the Invention This application provides a method and apparatus for terminating OAM messages within a service domain, which can ensure reliable termination of OAM messages within the service domain under conditions of asymmetric OAM configuration.

[0006] In a first aspect, embodiments of this application provide an OAM message domain termination method, the OAM message domain termination method comprising: After the local device creates a service, it determines whether the service is an end station node type; If it is the aforementioned terminal node type, then create a corresponding number of maintenance endpoint MEP entries according to the aforementioned service protection type; Configure the destination port of the MEP entry to the CPU port and set it to do nothing, so that when the local OAM is not created or creation fails, the OAM message is terminated in the service domain.

[0007] In conjunction with the first aspect, in one implementation, configuring the destination port of the MEP entry as a CPU port and setting it to be unprocessed includes: Assign an MEP entry number based on the business type; Configure the MEP mode and service parameters, and associate the MEP with the service interface; The MEP destination port is set to the CPU port, and the OAM messages received from the CPU port are configured not to be processed.

[0008] In conjunction with the first aspect, in one implementation, the step of assigning MEP entry numbers according to the service type includes: When the service is an EOO / EOS service, the MEP entry number is assigned based on the service entry index ID and the UNI-side logical interface index ID; When the service is an MPLS-TP service, the MEP entry number is assigned based on the service entry index ID and the PW index ID.

[0009] In conjunction with the first aspect, in one implementation, configuring the MEP mode and service parameters includes: When the service is an EOO / EOS service, configure the MEP mode to UP mode and set the LEVEL level to the highest level; When the service is an MPLS-TP service, configure the MEP mode to DOWN mode and set the OAM type to VCOAM.

[0010] In conjunction with the first aspect, in one implementation, associating the MEP with the service interface includes: When the service is an EOO / EOS service, the MEP will be bound to the UNI-side logical interface and associated with the interface LIF information; When the service is an MPLS-TP service, the MEP is bound to the PW and associated with the PW LIF information, and the PW LABEL is used as the inner matching label.

[0011] In conjunction with the first aspect, in one implementation, it further includes: Once the local OAM is successfully created, the MEP destination port is pointed to the OAM processing port, and the service parameters are modified to values ​​consistent with the service configuration.

[0012] In conjunction with the first aspect, in one implementation, creating a corresponding number of maintenance endpoint (MEP) entries based on the service protection type includes: If the business protection type is protected, then create two MEP entries; If the business protection type is no protection, then create a MEP entry.

[0013] Secondly, embodiments of this application provide an OAM message domain termination device, the OAM message domain termination device comprising: The judgment module is used to determine whether the service is an end station node type after the service is created on the local device; A creation module is used to create a corresponding number of maintenance endpoint (MEP) entries based on the service protection type when the service is an end station node type. The configuration module is used to configure the destination port of the MEP entry as the CPU port and set it to not process, so that when the local OAM is not created or creation fails, the OAM message is terminated in the service domain.

[0014] In conjunction with the second aspect, in one implementation, the configuration module configures the destination port of the MEP entry as a CPU port and sets it to be left unprocessed, including: Assign an MEP entry number based on the business type; Configure the MEP mode and service parameters, and associate the MEP with the service interface; The MEP destination port is set to the CPU port, and the OAM messages received from the CPU port are configured not to be processed.

[0015] In conjunction with the second aspect, in one implementation, the configuration module assigns MEP entry numbers according to the service type, including: When the service is an EOO / EOS service, the MEP entry number is assigned based on the service entry index ID and the UNI-side logical interface index ID; When the service is an MPLS-TP service, the MEP entry number is assigned based on the service entry index ID and the PW index ID.

[0016] The beneficial effects of the technical solutions provided in this application include at least the following: The OAM message domain termination method in this application determines whether the service is an end-node type after the service is created on the local device. If it is an end-node type, a corresponding number of maintenance endpoint (MEP) entries are created according to the service protection type. The destination port of the MEP entries is configured as the CPU port and set to not be processed, so that when the local OAM is not created or creation fails, the OAM message is terminated within the service domain. This achieves the technical effect of reliably terminating OAM messages within the service domain when the local OAM is not created or fails to be created. This effectively avoids network security risks and false alarms caused by OAM messages being incorrectly transmitted to the user end. At the same time, this configuration is only executed on the end station node, avoiding unnecessary resource occupation on the transit device and ensuring the rational use of network resources. Attached Figure Description

[0017] Figure 1 This is a flowchart of an embodiment of the OAM message field termination method of this application; Figure 2 When creating EOO / EOS services for this application, the principle diagram of OAM message termination implementation within the service domain is shown. Figure 3 This is a schematic diagram illustrating the implementation principle of OAM message termination within the service domain when deleting EOO / EOS services in this application. Figure 4 The schematic diagram was modified to accommodate the CFMOAM function of this application; Figure 5 When creating MPLS-TP services for this application, the schematic diagram of OAM message termination implementation within the service domain is shown. Figure 6 This is a schematic diagram illustrating the implementation principle of OAM message termination within the service domain when deleting MPLS-TP services in this application. Figure 7 The schematic diagram has been modified to accommodate the TPOAM function of this application; Figure 8 This is a structural block diagram of an embodiment of the OAM message domain termination device of this application. Detailed Implementation

[0018] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0020] Firstly, embodiments of this application provide a method for terminating OAM messages within a domain.

[0021] In one embodiment, reference is made to Figure 1 As shown, Figure 1 This is a flowchart illustrating an embodiment of the OAM message field termination method of this application. Figure 1 As shown, the termination methods within the OAM message field include: S1. After the local device creates a service, it determines whether the service is an end station node type; First, the hierarchical structure of the services in this embodiment will be introduced: MPLS-TP is the top-level transport network technology framework and the underlying transport technology, which includes two main service types: Tunneling: Used for network layer transmission; Pseudowire (PW): Used to simulate point-to-point connections.

[0022] VPWS (Virtual Private Wire Service) is an implementation method of pseudowire service, belonging to the service type within the MPLS-TP framework, providing point-to-point leased line service.

[0023] EOO / EOS is a specific business application based on VPWS: Among them, EOO (Ethernet over Optical) is Ethernet service based on optical transmission networks, typically carried by VPWS; EOS (Ethernet over SDH) is Ethernet service based on SDH transmission networks, typically carried by VPWS. Both are specific implementations of Ethernet services on VPWS.

[0024] Furthermore, for Ethernet services (EOO / EOS), CFMOAM (Connectivity Fault Management OAM) is used as the OAM mechanism. CFMOAM is used to detect connectivity faults in Ethernet links.

[0025] MPLS-TP services (tunneling services + pseudowire services) use TPOAM (Transport Pseudowire OAM) as the OAM mechanism. TPOAM is used to detect the connectivity of the MPLS-TP network.

[0026] It is worth noting that the purpose of this embodiment is to ensure that OAM messages can terminate within the service domain under asymmetric OAM configuration conditions, without affecting the normal forwarding of OAM messages during transit services. If the service is not an end-node type, no processing is performed. In other words, this application only takes effect when the end-node (service start / end point) fails in OAM configuration. The transit device (transfer device) always follows the normal OAM forwarding path, thus not affecting the normal forwarding of OAM messages for transit services.

[0027] S2. If it is the terminal node type, then create a corresponding number of maintenance endpoint MEP entries according to the service protection type; MEP (Maintenance End Point) is the start / end point of OAM function. In normal scenarios, MEP is responsible for sending / receiving OAM messages.

[0028] It is understandable that two MEP entries are created when there is protection because the protection mechanism has multiple independent business paths (main path + protection path), and each path requires an independent OAM termination mechanism; when there is no protection, there is only one business path, and only one MEP entry is needed.

[0029] S3. Configure the destination port of the MEP entry to the CPU port and set it to not process, so that when the local OAM is not created or creation fails, the OAM message is terminated in the service domain.

[0030] It is worth noting that setting the destination address of the OAM message to the CPU means that the message is forced to be sent to the control plane (CPU processing). After the CPU receives the message, it will discard it directly without any OAM processing logic.

[0031] Compared to existing technologies, where OAM packets are incorrectly forwarded to users due to devices' inability to process them because of asymmetric OAM configuration, this embodiment creates a special MEP (Merchant Entity Preservation) with its destination port pointing to the CPU, where the CPU does not process the packets. Thus, the CPU discards the received packets without any processing logic, terminating the packets internally (without entering the user network). This securely traps OAM packets within the device, resolving the configuration asymmetry problem and maintaining network robustness. Furthermore, if OAM configuration is successful, it automatically switches back to a normal MEP for proper packet processing.

[0032] In summary, after creating a service, this application first determines if the service is an end-node type and creates a MEP entry accordingly. Then, based on the service protection type, it determines the number of MEP entries to create. Finally, by pointing the MEP destination port to the CPU port and performing no processing, it ensures that in scenarios with different service types (EOO / EOS / MPLS-TP) and overlapping protection, OAM messages can still terminate within the domain when the local OAM is not created or fails to be created, while not affecting the normal forwarding of OAM messages during transit services. Once the local OAM is created, by re-specifying the MEP destination port and modifying the LEVEL level, it ensures that the normal OAM function is not affected.

[0033] In practice, based on the different characteristics of EOO / EOS / MPLS-TP services, MEPs can be directly associated with the UNI logical interface of the EOO / EOS service or the PW of the MPLS-TP service. This allows a service to map multiple MEPs when OAM is not created, and to accurately match different services through information such as the mode, level, type, label, and associated LIF value of the MEP.

[0034] The following specific examples will further illustrate this point: For EOO / EOS business: See Figure 2 As shown, when creating an EOO / EOS service, the service type is first determined. If it is not a UNI-NNI end-station node type, no processing is performed; if it is a UNI-NNI end-station node type, the service is further determined to see if it has UNI protection. If it has protection, two MEP entries are created; if it has no protection, one MEP entry is created.

[0035] The created MEP entry requires the following configuration: The first step is to allocate MEP entry numbers based on VPN_ID+LOGIC_PORT_ID, where VPN_ID is the service entry index ID and LOGIC_PORT_ID is the UNI-side logical interface index ID; The second step is to configure the MEP mode as UP mode and the LEVEL level as 7. The third step is to bind the MEP to the UNI-side logical interface and associate the interface LIF information; The fourth step is to point the MEP destination port to the CPU port, and not to process the OAM messages received from the CPU port.

[0036] See Figure 3 As shown, when deleting an EOO / EOS service, the service type is first determined. If it is not a UNI-NNI end-station node type, no processing is performed; if it is a UNI-NNI end-station node type, the service is further determined to see if it has UNI protection. If it has protection, two MEP entries are deleted; if it has no protection, one MEP entry is deleted. When deleting an MEP entry, the MEP entry number is queried based on VPN_ID + LOGIC_PORT_ID.

[0037] See Figure 4As shown, when creating a CFMOAM, the OAM mode needs to be determined first. If it is in OUTWARD mode, the normal process is followed; if it is in INWARD mode, the VPN_ID associated with the logical interface bound to the CFMOAM is queried, and then the MEP entry number is queried based on VPN_ID + LOGIC_PORT_ID. Based on the queried MEP entry, the following configuration modifications are required: First, modify the LEVEL level according to the OAM parameters; second, modify the destination port (CPU port, FPGA port, etc.) of different types of OAM packets to point to the MEP; then proceed with the normal packet reception and parsing process.

[0038] When deleting a CFMOAM, the OAM mode must first be determined. If it's in OUTWARD mode, proceed with the normal process. If it's in INWARD mode, query the VPN_ID associated with the logical interface bound to the CFMOAM, and then query the MEP entry number based on VPN_ID + LOGIC_PORT_ID. Based on the retrieved MEP entry, the following configuration modifications are required: First, restore the LEVEL level to 7; second, point the MEP destination port to the CPU port, and do not process OAM packets received from the CPU port. Then proceed with the normal CFMOAM deletion process.

[0039] For MPLS-TP services: See Figure 5 As shown, when creating an MPLS-TP service, the service type is first determined. If it is not a UNI-NNI end-station node type, no processing is performed; if it is a UNI-NNI end-station node type, the system further determines whether the service has PW protection. If there is protection, two MEP entries are created; if there is no protection, one MEP entry is created.

[0040] The created MEP entry requires the following configuration: The first step is to assign an MEP entry number based on VPN_ID+VC_ID, where VPN_ID is the service entry index ID and VC_ID is the PW index ID; The second step is to configure the MEP mode as DOWN mode and VCOAM type. The third step is to bind the MEP to the PW and associate it with the PW LIF information, using the PW LABEL as the inner matching tag. The fourth step is to point the MEP destination port to the CPU port, and not to process the OAM messages received from the CPU port.

[0041] See Figure 6As shown, when deleting an MPLS-TP service, the service type is first determined. If it is not a UNI-NNI end-station node type, no processing is performed; if it is a UNI-NNI end-station node type, the process continues to determine whether the service has PW protection. If it has protection, two MEP entries are deleted; if it has no protection, one MEP entry is deleted. When deleting an MEP entry, the MEP entry number is queried based on VPN_ID + VC_ID.

[0042] See Figure 7 As shown, when creating a TPOAM, the OAM type first needs to be determined. If it is VSOAM or VPOAM, the normal process is followed. If it is VCOAM, the VPN_ID associated with the PW bound to the VCOAM is queried, and then the MEP entry number is queried based on VPN_ID + VC_ID. According to the queried MEP entry, the destination port (CPU port, FPGA port, etc.) of different types of OAM packets needs to be modified; then the normal packet receiving and parsing process is followed.

[0043] When deleting a TPOAM, the OAM type must first be determined. If it is VSOAM or VPOAM, proceed with the normal process. If it is VCOAM, query the VPN_ID associated with the PW bound to the VCOAM, and then query the MEP entry number based on VPN_ID + VC_ID. Based on the queried MEP entry, the MEP destination port needs to be pointed to the CPU port, and OAM packets received from the CPU port are not processed; then proceed with the normal packet reception and parsing process.

[0044] In summary, the OAM message domain termination method in this application determines whether the service is an end-node type after the service is created on the local device. If it is an end-node type, a corresponding number of maintenance endpoint (MEP) entries are created according to the service protection type. The destination port of the MEP entries is configured as the CPU port and set to not be processed, so that when the local OAM is not created or creation fails, the OAM message is terminated within the service domain. This achieves the technical effect of reliably terminating OAM messages within the service domain when the local OAM is not created or fails to be created. This effectively avoids network security risks and false alarms caused by OAM messages being incorrectly transmitted to the user end. At the same time, this configuration is only executed on the end station node, avoiding unnecessary resource occupation on the transit device and ensuring the rational use of network resources.

[0045] Secondly, embodiments of this application provide an OAM message domain termination device.

[0046] In one embodiment, reference is made to Figure 8 As shown, Figure 8 This is a structural block diagram of an embodiment of the OAM message field termination device of this application. Figure 8As shown, the OAM message field termination device includes: The judgment module is used to determine whether the service is an end station node type after the service is created on the local device; A creation module is used to create a corresponding number of maintenance endpoint (MEP) entries based on the service protection type when the service is an end station node type. The configuration module is used to configure the destination port of the MEP entry as the CPU port and set it to not process, so that when the local OAM is not created or creation fails, the OAM message is terminated in the service domain.

[0047] Further, in one embodiment, the configuration module configures the destination port of the MEP entry to the CPU port and sets it to be left unprocessed, including: Assign an MEP entry number based on the business type; Configure the MEP mode and service parameters, and associate the MEP with the service interface; The MEP destination port is set to the CPU port, and the OAM messages received from the CPU port are configured not to be processed.

[0048] Furthermore, in one embodiment, the configuration module assigns MEP entry numbers according to the service type, including: When the service is an EOO / EOS service, the MEP entry number is assigned based on the service entry index ID and the UNI-side logical interface index ID; When the service is an MPLS-TP service, the MEP entry number is assigned based on the service entry index ID and the PW index ID.

[0049] Furthermore, in one embodiment, the configuration module configures the MEP mode and service parameters, including: When the service is an EOO / EOS service, configure the MEP mode to UP mode and set the LEVEL level to the highest level; When the service is an MPLS-TP service, configure the MEP mode to DOWN mode and set the OAM type to VCOAM.

[0050] Furthermore, in one embodiment, the configuration module associating the MEP with the service interface includes: When the service is an EOO / EOS service, the MEP will be bound to the UNI-side logical interface and associated with the interface LIF information; When the service is an MPLS-TP service, the MEP is bound to the PW and associated with the PW LIF information, and the PW LABEL is used as the inner matching label.

[0051] Furthermore, in one embodiment, the configuration module is also used for: Once the local OAM is successfully created, the MEP destination port is pointed to the OAM processing port, and the service parameters are modified to values ​​consistent with the service configuration.

[0052] Furthermore, in one embodiment, the creation module creates a corresponding number of Maintenance Endpoint (MEP) entries based on the service protection type, including: If the business protection type is protected, then create two MEP entries; If the business protection type is no protection, then create a MEP entry.

[0053] The functions of each module in the OAM message domain termination device correspond to the steps in the OAM message domain termination method embodiment, and their functions and implementation processes will not be described in detail here.

[0054] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0055] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0056] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0057] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0058] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0059] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0060] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for terminating an OAM message field, characterized in that, The OAM message field termination method includes: After the local device creates a service, it determines whether the service is an end station node type; If it is the aforementioned terminal node type, then create a corresponding number of maintenance endpoint MEP entries according to the aforementioned service protection type; Configure the destination port of the MEP entry to the CPU port and set it to do nothing, so that when the local OAM is not created or creation fails, the OAM message is terminated in the service domain.

2. The OAM message field termination method as described in claim 1, characterized in that, The configuration of the MEP entry with the destination port set to the CPU port and set to no processing includes: Assign an MEP entry number based on the business type; Configure the MEP mode and service parameters, and associate the MEP with the service interface; The MEP destination port is set to the CPU port, and the OAM messages received from the CPU port are configured not to be processed.

3. The OAM message field termination method as described in claim 2, characterized in that, The process of assigning MEP entry numbers based on the business type includes: When the service is an EOO / EOS service, the MEP entry number is assigned based on the service entry index ID and the UNI-side logical interface index ID; When the service is an MPLS-TP service, the MEP entry number is assigned based on the service entry index ID and the PW index ID.

4. The OAM message field termination method as described in claim 3, characterized in that, The configuration of MEP mode and service parameters includes: When the service is an EOO / EOS service, configure the MEP mode to UP mode and set the LEVEL level to the highest level; When the service is an MPLS-TP service, configure the MEP mode to DOWN mode and set the OAM type to VCOAM.

5. The OAM message field termination method as described in claim 3, characterized in that, The association of MEP with the service interface includes: When the service is an EOO / EOS service, the MEP will be bound to the UNI-side logical interface and associated with the interface LIF information; When the service is an MPLS-TP service, the MEP is bound to the PW and associated with the PW LIF information, and the PW LABEL is used as the inner matching label.

6. The OAM message field termination method as described in claim 2, characterized in that, Also includes: Once the local OAM is successfully created, the MEP destination port is pointed to the OAM processing port, and the service parameters are modified to values ​​consistent with the service configuration.

7. The OAM message field termination method as described in claim 1, characterized in that, The step of creating a corresponding number of maintenance endpoint MEP entries based on the service protection type includes: If the business protection type is protected, then create two MEP entries; If the business protection type is no protection, then create a MEP entry.

8. An OAM message domain termination device, characterized in that, The OAM message field termination includes: The judgment module is used to determine whether the service is an end station node type after the service is created on the local device; A creation module is used to create a corresponding number of maintenance endpoint (MEP) entries based on the service protection type when the service is an end station node type. The configuration module is used to configure the destination port of the MEP entry as the CPU port and set it to not process, so that when the local OAM is not created or creation fails, the OAM message is terminated in the service domain.

9. The OAM message domain termination device as described in claim 8, characterized in that, The configuration module configures the destination port of the MEP entry to the CPU port and sets it to be left unprocessed, including: Assign an MEP entry number based on the business type; Configure the MEP mode and service parameters, and associate the MEP with the service interface; The MEP destination port is set to the CPU port, and the OAM messages received from the CPU port are configured not to be processed.

10. The OAM message domain termination device as described in claim 9, characterized in that, The configuration module assigns MEP entry numbers based on the service type, including: When the service is an EOO / EOS service, the MEP entry number is assigned based on the service entry index ID and the UNI-side logical interface index ID; When the service is an MPLS-TP service, the MEP entry number is assigned based on the service entry index ID and the PW index ID.