CN105515816A - Processing method and apparatus for detection level information - Google Patents
Processing method and apparatus for detection level information Download PDFInfo
- Publication number
- CN105515816A CN105515816A CN201410559786.0A CN201410559786A CN105515816A CN 105515816 A CN105515816 A CN 105515816A CN 201410559786 A CN201410559786 A CN 201410559786A CN 105515816 A CN105515816 A CN 105515816A
- Authority
- CN
- China
- Prior art keywords
- sfcoam
- detection
- service
- information
- service node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000001514 detection method Methods 0.000 title claims abstract description 302
- 238000003672 processing method Methods 0.000 title claims abstract description 15
- 238000000034 method Methods 0.000 claims abstract description 32
- 238000012545 processing Methods 0.000 claims description 52
- 230000004044 response Effects 0.000 claims description 44
- 230000008569 process Effects 0.000 claims description 16
- 238000012423 maintenance Methods 0.000 claims description 11
- 238000004806 packaging method and process Methods 0.000 claims description 7
- 238000010586 diagram Methods 0.000 description 25
- 238000005516 engineering process Methods 0.000 description 11
- 230000007246 mechanism Effects 0.000 description 11
- 238000007726 management method Methods 0.000 description 9
- 238000005538 encapsulation Methods 0.000 description 8
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a processing method and apparatus for detection level information. In the method, a source end service node determines SFC OAM detection level information and packages the SFC OAM detection level information in an SFC OAM detection packet, the SFC OAM detection level information being used for indicating SFC OAM detection among peer entities at the same level in different service nodes; and the source end service node transmits the SFC OAM detection packet to a destination end service node. The technical scheme of the invention can be used for flexible definition and management of OAM detection levels.
Description
Technical Field
The present invention relates to the field of communications, and in particular, to a processing method and apparatus for detecting hierarchical information.
Background
Service Function Chaining (SFC) is a network technology that is currently being researched and standardized. Since the development of data center networks into Overlay (Overlay) networks, the network edge, which may be a Server (Server) or top-of-rack (ToR) switch, and may be a Gateway (Gateway), has become the demarcation point between virtual and physical networks. However, the Overlay technology cannot solve all the problems, and there are many Middleware (middlewares) in the data center, for example: firewalls/load balancers, etc., which are handled based on user traffic, are clearly not feasible if tunneled through them.
This deployment model for data centers requires that virtual firewalls/load balancers can be deployed arbitrarily in the network, i.e., independent of the network topology; the defects are as follows: if the traffic can be flexibly processed through the virtual firewall/load balancer, a new type of middleware such as the virtual firewall/load balancer is generated, and the virtual firewall/load balancer is deployed at the edge of the network and can be realized by a standard server.
In the related art, the service processing functions such as the virtual firewall, the load balancer, and the gateway are referred to as service functions (servicefunctions), and a series of servicefunctions are performed on the traffic to form servicefunctional chaining.
Currently, the SFC framework in the related art can be basically divided into the following components:
1. service Overlay, that is, an Overlay technology in which each network edge node needs to communicate;
2. a Generic Service Control Plane (GSCP), which is a controller for forming servicefunctional chaining;
3. a service classifier (ServiceClassification), namely, a flow identification is required, and then a specific servicefunctional changing process is performed on a specific flow;
4. a Service Function (SF), a component that performs service processing on data packets;
5. service Function Forwarder (SFF), a data packet is transmitted between nodes of a service function chain, and a layer of service function header (NSH) is encapsulated outside a data frame. This header is parsed, encapsulated and decapsulated by the service function forwarder component on the service function node. The format of the service function header is specifically shown in fig. 1.
6. A Network Forwarder (NF) responsible for forwarding among multiple SFFs inside the same service node and encapsulating and decapsulating an Overlay layer for an Overlay data packet; meanwhile, forwarding among different service nodes can be processed;
7. a Service Function Path (SFP) for short, and fig. 2 is a schematic diagram of a service function path according to the related art. As shown in fig. 2, SFP is a traffic processing path that starts from the classifier, passes through several instances of traffic function, and finally reaches the destination. In some cases, the Generic Service Control Platform (GSCP) cannot know all service function instances passing along the way, for example: a load sharing scenario or a service class scenario, and at this time, the description of the service function chain between the abstract service function chain SFC and a path formed by the ordered service instances through which the real and concrete traffic is forwarded is also referred to as a service function path. A service function chain may include multiple service function paths, with different service function paths corresponding to different policies.
8. Control plane Metadata (datalinemetadata), which is a big feature, allows various service function nodes to exchange information with each other, thereby achieving a specific service processing purpose.
In summary, the SFC is a technology for separating the service function and the forwarding of the network device, which realizes independent operation and processing of the service function and improves the forwarding performance of the network device.
An Operation, administration and maintenance (OAM) technology is a network transmission protocol for network connectivity detection, fault location and troubleshooting, and a trigger mechanism capable of providing protection switching when a fault occurs, and includes a link connectivity detection (CV) mechanism, a Ping mechanism and a Trace mechanism. For different bearer network protocols, there are corresponding OAM mechanisms. For example: an ethernet OAM protocol exists in an ethernet network, an IPOAM protocol exists in an IP network, and an MPLS network includes MPLS OAM.
Currently, the technical framework and implementation details of the SFCOAM technique are being discussed. Fig. 3 is a technical framework diagram of SFCOAM according to the related art. As shown in fig. 3, the core idea is to diagnose the link condition between service function chains or service functions. Fig. 4 is a diagram illustrating an SFCOAM message format according to the related art. As shown in fig. 4, a field may be reserved in the service function header NSH for identifying OAM message and OAM message type. Fig. 5 is a diagram illustrating another SFCOAM message format according to the related art. As shown in fig. 5, 1 Bit (Bit) may be reserved in the service function header NSH for identifying that the OAM message is, and as for which type of OAM message is, the Bit may be set in a message other than the service function header NSH. However, in any case, it is impossible to solve the hierarchical problem of SFCOAM, i.e. whether to diagnose connectivity between service nodes experienced by a service function chain or connectivity between Service Function Forwarders (SFFs) on service nodes experienced by a service function chain, or connectivity between SFs managed by a Service Function Forwarder (SFF) experienced by a service function chain.
In summary, the existing SFCOAM technology cannot flexibly define and manage the OAM detection level.
Disclosure of Invention
The embodiment of the invention provides a processing method and a processing device for detection level information, which are used for at least solving the problem that the OAM detection level of the existing SFCOAM technology cannot be flexibly defined and managed.
According to one aspect of the invention, a processing method for detecting hierarchical information is provided.
The processing method for detecting the hierarchical information according to the embodiment of the invention comprises the following steps: a source service node determines Service Function Chain (SFC) operation, management and maintenance (OAM) detection level information and encapsulates the SFCOAM detection level information in an SFCOAM detection message, wherein the SFCOAM detection level information is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes; and the source service node sends an SFCOAM detection message to the destination service node.
Preferably, the determining, by the source service node, the SFCOAM detection hierarchy information includes: a source service node acquires various SFCOAM detection levels which are currently selected; the source service node selects at least one SFCOAM detection level from a plurality of SFCOAM detection levels.
Preferably, the plurality of SFCOAM detection levels includes at least one of: SFCOAM detection hierarchy between different service nodes experienced by a service function chain; SFCOAM detection hierarchy between service function forwarders SFF on different service nodes experienced by a service function chain; SFCOAM detection hierarchy between service functions SF managed by SFFs on different service nodes experienced by a service function chain, respectively.
Preferably, the SFCOAM detection level information is encapsulated in a specific bit of the service function header NSH or the SFCOAM detection level information is encapsulated in the rest of the headers except for NSH.
Preferably, the source service node is a service classifier or one of the service nodes in the service function chain.
Preferably, the destination service node is a remaining service node or a combination of a plurality of service nodes on the service function chain except the source service node.
Preferably, the SFCOAM detection message includes one of the following types: connectivity detection messages, Ping messages and Trace messages.
According to another aspect of the present invention, another processing method for detecting hierarchical information is provided.
The processing method for detecting the hierarchical information according to the embodiment of the invention comprises the following steps: a destination service node receives a service function chain SFC operation, management and maintenance OAM detection message from a source service node, wherein the SFCOAM detection message carries SFCOAM detection level information which is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes; and the target end service node analyzes SFCOAM detection level information from the SFCOAM detection message and determines an SFCOAM response message to be fed back according to the SFCOAM detection level information.
Preferably, the destination service node determines, according to the SFCOAM detection level information, that the SFCOAM response packet includes one of the following: when the SFCOAM detection level information is the SFCOAM detection level between different service nodes experienced by the service function chain, the destination service node directly processes the SFCOAM detection message, and after the SFCOAM detection message is processed, the information carried in the SFCOAM response message comprises at least one of the following information: node information of a destination end service node, connectivity information of the destination end service node and path information of the destination end service node; when the SFCOAM detection level information is the SFCOAM detection level between the service function forwarders SFFs on different service nodes experienced by the service function chain, the destination service node forwards the SFCOAM detection message to the SFF to process the SFCOAM message, and after the SFF finishes processing the SFCOAM message, the information carried in the SFCOAM response message comprises at least one of the following information: the connectivity information of the SFF of the service node of the destination end, the path information of the SFF and the service level protocol information of the SFF; when the SFCOAM detection level information is the SFCOAM detection level between service functions SF respectively managed by different SFFs experienced by a service function chain, the destination service node forwards the SFCOAM detection message to the SFF for processing, and then forwards the SFCOAM detection message to the SF for processing, and after the SFF and the SF finish processing the SFCOAM detection message, the information carried in the SFCOAM response message comprises at least one of the following information: service function information of SF, connectivity information of SF, path information of SF and service level protocol information of SF under SFF management of a destination service node.
According to still another aspect of the present invention, there is provided a processing apparatus for detecting hierarchical information.
The processing device for detecting the hierarchical information according to the embodiment of the invention comprises: the system comprises a determining module, a detecting module and a judging module, wherein the determining module is used for determining the operation, management and maintenance OAM detection level information of a service function chain SFC and packaging the SFCOAM detection level information in an SFCOAM detection message, and the SFCOAM detection level information is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes; and the sending module is used for sending the SFCOAM detection message to the destination service node.
Preferably, the determining module comprises: the acquisition unit is used for acquiring various currently-alternative SFCOAM detection levels; and the selection unit is used for selecting one SFCOAM detection level from the multiple SFCOAM detection levels.
Preferably, the plurality of SFCOAM detection levels includes at least one of: SFCOAM detection hierarchy between different service nodes experienced by a service function chain; SFCOAM detection hierarchy between service function forwarders SFF on different service nodes experienced by a service function chain; SFCOAM detection hierarchy between service functions SF managed by SFFs on different service nodes experienced by a service function chain, respectively.
Preferably, the SFCOAM detection level information is encapsulated in a specific bit of the service function header NSH or the SFCOAM detection level information is encapsulated in the rest of the headers except for NSH.
Preferably, the source service node is a service classifier or one of the service nodes in the service function chain.
Preferably, the destination service node is a remaining service node or a combination of a plurality of service nodes on the service function chain except the source service node.
Preferably, the SFCOAM detection message includes one of the following types: connectivity detection messages, Ping messages and Trace messages.
According to another aspect of the present invention, another processing apparatus for detecting hierarchical information is provided.
The processing device for detecting the hierarchical information according to the embodiment of the invention comprises: a receiving module, configured to receive an operation, administration, and maintenance OAM detection packet of a service function chain SFC from a source service node, where the SFCOAM detection packet carries SFCOAM detection level information, and the SFCOAM detection level information is used to indicate that SFCOAM detection is performed between peer entities belonging to the same level in different service nodes; and the processing module is used for analyzing the SFCOAM detection level information from the SFCOAM detection message and determining an SFCOAM response message to be fed back according to the SFCOAM detection level information.
Preferably, the processing module is configured to directly process the SFCOAM detection packet when the SFCOAM detection level information is an SFCOAM detection level between different service nodes experienced by the service function chain, and after the SFCOAM detection packet is processed, information carried in the SFCOAM response packet includes at least one of the following: node information of a destination end service node, connectivity information of the destination end service node and path information of the destination end service node; or when the SFCOAM detection level information is the SFCOAM detection level between the SFFs on different service nodes experienced by the service function chain, forwarding the SFCOAM detection message to the SFF for processing the SFCOAM message, and after the SFF finishes processing the SFCOAM message, the information carried in the SFCOAM response message includes at least one of the following: the connectivity information of the SFF of the service node of the destination end, the path information of the SFF and the service level protocol information of the SFF; or when the SFCOAM detection level information is the SFCOAM detection level between service functions SF managed by different SFFs experienced by the service function chain, the SFCOAM detection message is forwarded to the SFF for processing and then forwarded to the SF for processing until the SFF and the SF finish processing the SFCOAM detection message, and the information carried in the SFCOAM response message includes at least one of the following: service function information of SF, connectivity information of SF, path information of SF and service level protocol information of SF under SFF management of a destination service node.
According to the embodiment of the invention, a source service node is adopted to determine the operation, management and maintenance OAM detection level information of a service function chain SFC, and the SFCOAM detection level information is encapsulated in an SFCOAM detection message, wherein the SFCOAM detection level information is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes; the source service node sends the SFCOAM detection message to the destination service node, so that the problem that the OAM detection level of the existing SFCOAM technology cannot be flexibly defined and managed is solved, and the OAM detection level can be flexibly defined and managed.
Drawings
The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the invention without limiting the invention. In the drawings:
fig. 1 is a schematic diagram of a service function header message format according to the related art;
fig. 2 is a schematic diagram of a traffic function path according to the related art;
fig. 3 is a technical framework diagram of SFCOAM according to the related art;
fig. 4 is a schematic diagram of an SFCOAM message format according to the related art;
fig. 5 is a schematic diagram of another SFCOAM message format according to the related art;
FIG. 6 is a flow chart of a processing method of detecting hierarchical information according to an embodiment of the present invention;
FIG. 7 is a schematic diagram of the overall architecture of an SFC in accordance with a preferred embodiment of the present invention;
fig. 8 is a schematic diagram of an SFCOAM packet format carrying SFCOAM detection hierarchy information according to an embodiment of the present invention;
fig. 9 is a schematic diagram of another SFCOAM packet format carrying SFCOAM detection hierarchy information according to the preferred embodiment of the present invention;
FIG. 10 is a flow chart of another processing method for detecting hierarchical information according to an embodiment of the present invention;
FIG. 11 is a schematic diagram of a mechanism for connectivity detection between tier one based service nodes in accordance with a preferred embodiment of the present invention;
fig. 12 is a schematic diagram of the Ping mechanism between tier two based service nodes in accordance with the preferred embodiment of the present invention;
FIG. 13 is a schematic diagram of the Trace mechanism for a layer three based service function path in accordance with the preferred embodiment of the present invention;
fig. 14 is a block diagram of a configuration of a processing apparatus that detects hierarchical information according to an embodiment of the present invention;
fig. 15 is a block diagram of another processing apparatus for detecting hierarchical information according to an embodiment of the present invention.
Detailed Description
The invention will be described in detail hereinafter with reference to the accompanying drawings in conjunction with embodiments. It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict.
Fig. 6 is a flowchart of a processing method of detecting hierarchical information according to an embodiment of the present invention. As shown in fig. 6, the method may include the following process steps:
step S602: a source service node determines SFCOAM detection level information and encapsulates the SFCOAM detection level information in an SFCOAM detection message, wherein the SFCOAM detection level information is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes;
step S604: and the source service node sends an SFCOAM detection message to the destination service node.
The SFCOAM technology provided in the related art cannot flexibly define and manage the OAM detection level thereof. By adopting the method shown in fig. 1, the hierarchical relationship between different service nodes, or the hierarchical relationship between service function repeaters of different service nodes, or the hierarchical relationship between service functions under the management of the service function repeaters of different service nodes, is encapsulated in the SFCOAM detection message and is notified to the destination service node. Therefore, the problem that the OAM detection level of the existing SFCOAM technology cannot be flexibly defined and managed is solved, and the OAM detection level can be flexibly defined and managed.
Preferably, in step S602, the source service node determining SFCOAM detection hierarchy information may include the following operations:
step S1: a source service node acquires various SFCOAM detection levels which are currently selected;
step S2: the source service node selects at least one SFCOAM detection level from a plurality of SFCOAM detection levels.
Preferably, the SFCOAM detection layers may include at least one of:
(1) SFCOAM detection hierarchy between different service nodes experienced by a service function chain;
(2) SFCOAM detection hierarchy between service function forwarders SFF on different service nodes experienced by a service function chain;
(3) SFCOAM detection hierarchy between service functions SF managed separately by different SFFs experienced by a service function chain.
In a preferred embodiment, fig. 7 is a schematic diagram of the overall architecture of an SFC according to a preferred embodiment of the present invention. As shown in fig. 7, there are three SFCOAM levels in the SFC overall architecture:
layer 1: different service nodes experienced by the service function chain;
and (2) layer: service function chains go through between Service Function Forwarders (SFFs) on different service nodes;
and (3) layer: between SFs managed by different service function forwarders SFF experienced by a service function chain;
when the SFCOAM detection is initiated on the service function chain, the SFCOAM source service node in the service function chain can select one SFCOAM detection level from the three SFCOAM levels, and then the SFCOAM detection level is encapsulated in the SFCOAM message and then is sent to the destination service node.
Preferably, the SFCOAM detection level information may be encapsulated in a specific bit of a service function header NSH or the SFCOAM detection level information may be encapsulated in other headers except for NSH.
In a preferred embodiment, fig. 8 is a schematic diagram of an SFCOAM packet format carrying SFCOAM detection hierarchy information according to the preferred embodiment of the present invention. As shown in fig. 8, the SFCOAM detection hierarchy information may use dedicated bits, and the dedicated bits may be located in the service function header NSH. Fig. 9 is a schematic diagram of another SFCOAM packet format carrying SFCOAM detection hierarchy information according to the preferred embodiment of the present invention. As shown in fig. 9, the SFCOAM detection hierarchy information may be located in a header other than the service function header NSH.
In a preferred implementation, the source service node may be a service classifier or one of the service nodes in a service function chain.
In a preferred implementation, the destination service node may be one service node or a combination of a plurality of service nodes other than the source service node in the service function chain.
In a preferred implementation process, the SFCOAM detection packet may include, but is not limited to, one of the following types:
type one, connectivity verification (CV for short) message;
type two, Ping message;
type three, Trace message.
Fig. 10 is a flowchart of another processing method for detecting hierarchical information according to an embodiment of the present invention. As shown in fig. 10, the method may include the following process steps:
step S1002: a destination service node receives an SFCOAM detection message from a source service node, wherein the SFCOAM detection message carries SFCOAM detection level information which is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes;
step S1004: and the target end service node analyzes SFCOAM detection level information from the SFCOAM detection message and determines an SFCOAM response message to be fed back according to the SFCOAM detection level information.
Preferably, in step S1004, the destination service node determines, according to the SFCOAM detection hierarchy information, that the SFCOAM response packet may include one of the following:
(1) when the SFCOAM detection level information is the SFCOAM detection level between different service nodes experienced by the service function chain, the destination service node directly processes the SFCOAM detection message, and after the SFCOAM detection message is processed, the information carried in the SFCOAM response message comprises at least one of the following information: node information of a destination end service node, connectivity information of the destination end service node and path information of the destination end service node;
(2) when the SFCOAM detection level information is the SFCOAM detection level between the service function forwarders SFFs on different service nodes experienced by the service function chain, the destination service node forwards the SFCOAM detection message to the SFF to process the SFCOAM message, and after the SFF finishes processing the SFCOAM message, the information carried in the SFCOAM response message comprises at least one of the following information: the connectivity information of the SFF of the service node of the destination end, the path information of the SFF and the service level protocol information of the SFF;
(3) when the SFCOAM detection level information is the SFCOAM detection level between service functions SF respectively managed by different SFFs experienced by a service function chain, the destination service node forwards the SFCOAM detection message to the SFF for processing, and then forwards the SFCOAM detection message to the SF for processing, and after the SFF and the SF finish processing the SFCOAM detection message, the information carried in the SFCOAM response message comprises at least one of the following information: service function information of SF, connectivity information of SF, path information of SF and service level protocol information of SF under SFF management of a destination service node.
In a preferred embodiment, after receiving an SFCOAM detection packet carrying an SFCOAM detection level, a destination service node parses a detection level field from the SFCOAM detection packet. If the field identifies level 1, only returning an SFCOAM response message carrying at least one of the node information, the connectivity information and the path information of the service node; if the field identifies level 2, returning an SFCOAM response message carrying at least one of connectivity information and path information of the service forwarder of the service node; if the field identifies the layer 3, an SFCOAM response message carrying at least one of service function information, connectivity information, path information and Service Level Agreement (SLA) information of the service function managed by the service forwarder of the service node is returned.
The above preferred implementation will be further described with reference to the preferred embodiment shown in fig. 11 to 13.
Preferred embodiment 1
Fig. 11 is a schematic diagram of a mechanism for detecting connectivity between service nodes based on level one according to the preferred embodiment of the present invention. As shown in fig. 11, the process may include the following steps:
step one, a source end service node 1 constructs a connectivity detection message of SFCOAM carrying SFCOAM detection level fields, encapsulates the connectivity detection message in an Overlay layer and forwards the connectivity detection message to a next hop service node 2 along a service function chain, wherein the detection level field value carried in the connectivity detection message is 1, namely based on the connectivity detection between service nodes;
step two, the service node 2 receives the connectivity detection message, analyzes the SFCOAM detection level field from the connectivity detection message and finds that the SFCOAM detection level field is based on level one; meanwhile, if the service node 2 finds that the service node operates normally, the service node encapsulates the SFCOAM message carrying the SFCOAM detection level field in the Overlay layer again, and then forwards the connectivity detection message to the next-hop service node 3 along the service function chain;
step three, the service node 3 receives the connectivity detection message, analyzes the SFCOAM detection level field from the connectivity detection message and finds that the SFCOAM detection level field is based on level one; meanwhile, if the service node is found to be normal and is the destination service node, an SFCOAM connectivity detection response message carrying connectivity information is generated and encapsulated in an Overlay layer, and then the connectivity detection response message is forwarded hop by hop along a service function chain to the source service node 1.
Preferred embodiment two
Fig. 12 is a schematic diagram of a Ping mechanism between tier two based service nodes in accordance with a preferred embodiment of the present invention. As shown in fig. 12, the method may include the steps of:
step one, a source end service node 1 constructs a Ping message of SFCOAM carrying SFCOAM detection level fields, encapsulates the Ping message in an Overlay layer, and then forwards the Ping message to a next hop service node 2 along a service function chain, wherein the field value carrying the detection level fields is 2, namely based on connectivity detection between service function repeaters;
step two, the service node 2 receives the Ping message, analyzes the SFCOAM detection level field from the Ping message, finds that the detection level field is based on level two, and then forwards the SFC encapsulation message to a service function forwarder SFF experienced by a service function chain;
step three, the SFF detects whether the SFF operates normally; if the service node is normal, the service node 2 encapsulates the SFCOAM message carrying the SFCOAM detection level field in an Overlay layer, and forwards the SFCOAM message to a next-hop service node 3 along a service function chain;
step four, the service node 3 receives the SFCOAM message, analyzes the SFCOAM detection level field from the SFCOAM message, finds that the SFCOAM detection level field is based on level two, and then forwards the SFC encapsulation message to a service function forwarder SFF experienced by a service function chain;
step five, the service node 3 finds that the service node is already a destination service node, generates an SFCOAMPing response message after finding that the local SFF is normally operated, encapsulates the SFCOAMPing response message in an Overlay layer, and then forwards the response message to the source service node 1 hop by hop along a service function chain.
Preferred embodiment three
Fig. 13 is a schematic diagram of a Trace mechanism based on a layer three service function path according to the preferred embodiment of the present invention. As shown in fig. 13, the method may include the steps of:
step one, a source terminal ServiceClassifier constructs a TTL value as 1, encapsulates a Trace message of an SFCOAM carrying an SFCOAM detection layer field in an Overlay layer, and forwards the Trace message to a next hop service node 1 along a service function chain, wherein the carried detection layer field value is 3, namely, connectivity detection between service functions SF managed by a service function forwarder;
step two, the service node 1 receives the Trace message, analyzes the SFCOAM detection level field from the Trace message, finds that the detection level field is based on level three, and then forwards the SFC encapsulation message to a service function forwarder SFF experienced by a service function chain;
step three, the SFF forwards the SFC encapsulation message to the SF appointed by the service function path, and obtains at least one of the following information: service function information, function processing time information, bandwidth information and resource information of SF are encapsulated in a response message of SFCOAMTRACE;
step four, the service node 1 performs Overlay packaging on the response message of the SFCOAMTRACE, and forwards the response message to a serviceClassifier;
constructing TTL value as 2 by a source end serviceClassifier, encapsulating a Trace message of the SFCOAM carrying SFCOAM detection level field in an Overlay layer, and then forwarding the Trace message to a next hop service node 1 along a service function chain;
step six, the service node 1 performs Overlay encapsulation again, and then forwards the message to the service node 2;
step seven, the service node 2 receives the message encapsulated by the Overlay, analyzes the SFCOAM detection level field from the message, finds that the SFCOAM detection level field is based on level three, and then forwards the SFC encapsulation message to a service function forwarder SFF experienced by a service function chain;
step eight, the SFF forwards the SFC encapsulation message to the SF appointed by the service function path, and obtains at least one of the following information: service function information, function processing time information, bandwidth information and resource information of SF are encapsulated in a response message of SFCOAMTRACE;
step nine, the service node 2 performs Overlay packaging on the response message of the SFCOAMTRACE, and forwards the response message to the serviceClassiier hop by hop;
constructing TTL value as 3 by a source end serviceClassifier, encapsulating a Trace message of the SFCOAM carrying SFCOAM detection level field in an Overlay layer, and forwarding the Trace message to a next hop service node 1 along a service function chain;
step eleven, the service node 1 receives the Trace message, performs Overlay packaging again, and then forwards the Overlay packaged message to the service node 2;
step twelve, the service node 2 receives the Trace message, performs Overlay packaging again, and then forwards the Overlay packaged message to the service node 3;
step thirteen, the service node 3 receives the message encapsulated by Overlay, analyzes the SFCOAM detection level field from the message, finds that the SFCOAM detection level field is based on level three, and then forwards the SFC encapsulated message to a service function forwarder SFF experienced by a service function chain;
step fourteen, the SFF forwards the SFC encapsulation message to the SF appointed by the service function path, and obtains at least one of the following information: service function information, function processing time information, bandwidth information and resource information of SF are encapsulated in a response message of SFCOAMTRACE;
step fifteen, the service node 3 performs Overlay packaging on the response message of the SFCOAMTRACE, and forwards the response message to the serviceClassiier hop by hop.
Fig. 14 is a block diagram of a processing apparatus for detecting hierarchical information according to an embodiment of the present invention. As shown in fig. 14, the processing means for detecting hierarchical information may include: a determining module 10, configured to determine operation, administration, and maintenance OAM detection level information of a service function chain SFC, and encapsulate the SFCOAM detection level information in an SFCOAM detection message, where the SFCOAM detection level information is used to indicate that SFCOAM detection is performed between peer entities belonging to the same hierarchy in different service nodes; a sending module 20, configured to send the SFCOAM detection packet to a destination service node.
The device shown in fig. 14 is adopted to solve the problem that the existing SFCOAM technology cannot flexibly define and manage the OAM detection level, and further, the OAM detection level can be flexibly defined and managed.
Preferably, the determining module 10 may include: an obtaining unit (not shown in the figure) for obtaining a plurality of SFCOAM detection levels which are currently alternative; and a selecting unit (not shown in the figure) for selecting one of the SFCOAM detection levels from the multiple SFCOAM detection levels.
Preferably, the SFCOAM detection layers may include at least one of:
(1) SFCOAM detection hierarchy between different service nodes experienced by a service function chain;
(2) SFCOAM detection hierarchy between service function forwarders SFF on different service nodes experienced by a service function chain;
(3) SFCOAM detection hierarchy between service functions SF managed separately by different SFFs experienced by a service function chain.
Preferably, the SFCOAM detection level information may be encapsulated in a specific bit of a service function header NSH or the SFCOAM detection level information may be encapsulated in other headers except for NSH.
In a preferred implementation, the source service node may be a service classifier or one of the service nodes in a service function chain.
In a preferred implementation, the destination service node may be one service node or a combination of a plurality of service nodes other than the source service node in the service function chain.
In a preferred implementation process, the SFCOAM detection packet may include, but is not limited to, one of the following types:
type one, connectivity verification (CV for short) message;
type two, Ping message;
type three, Trace message.
Fig. 15 is a block diagram of another processing apparatus for detecting hierarchical information according to an embodiment of the present invention. As shown in fig. 15, the processing means for detecting hierarchical information may include: a receiving module 30, configured to receive an SFCOAM detection packet from a source service node, where the SFCOAM detection packet carries SFCOAM detection level information, and the SFCOAM detection level information is used to indicate that SFCOAM detection is performed between peer entities belonging to the same level in different service nodes; and the processing module 40 is configured to analyze SFCOAM detection level information from the SFCOAM detection packet, and determine an SFCOAM response packet to be fed back according to the SFCOAM detection level information.
In an optimal implementation process, the processing module 40 is configured to directly process an SFCOAM detection packet when SFCOAM detection level information is an SFCOAM detection level between different service nodes experienced by a service function chain, and after the SFCOAM detection packet is processed, information carried in an SFCOAM response packet includes at least one of the following: node information of a destination end service node, connectivity information of the destination end service node and path information of the destination end service node; or,
when the SFCOAM detection level information is the SFCOAM detection level between the service function forwarders SFFs on different service nodes experienced by the service function chain, the SFCOAM detection message is forwarded to the SFF to process the SFCOAM message, and after the SFF finishes processing the SFCOAM message, the information carried in the SFCOAM response message comprises at least one of the following information: the connectivity information of the SFF of the service node of the destination end, the path information of the SFF and the service level protocol information of the SFF; or,
when the SFCOAM detection level information is the SFCOAM detection level between service functions SF respectively managed by different SFFs experienced by a service function chain, the SFCOAM detection message is forwarded to the SFF for processing and then forwarded to the SF for processing, and the information carried in the SFCOAM response message comprises at least one of the following information after the SFF and the SF finish processing the SFCOAM detection message: service function information of SF, connectivity information of SF, path information of SF and service level protocol information of SF under SFF management of a destination service node.
From the above description, it can be seen that the above embodiments achieve the following technical effects (it is to be noted that these effects are those that certain preferred embodiments can achieve): by adopting the technical scheme provided by the embodiment of the invention, the hierarchical relationship among different service nodes, or the hierarchical relationship among service function repeaters of different service nodes, or the hierarchical relationship among service functions managed by the service function repeaters of different service nodes is encapsulated in the SFCOAM detection message and informs the service node of the destination end, so that the OAM detection hierarchy can be flexibly defined and managed.
It will be apparent to those skilled in the art that the modules or steps of the present invention described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.
The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (18)
1. A processing method for detecting hierarchical information is characterized by comprising the following steps:
a source service node determines operation, management and maintenance OAM detection level information of a service function chain SFC, and encapsulates the SFCOAM detection level information in an SFCOAM detection message, wherein the SFCOAM detection level information is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes;
and the source service node sends the SFCOAM detection message to a destination service node.
2. The method of claim 1, wherein the source service node determining the SFCOAM detection hierarchy information comprises:
the source service node acquires various SFCOAM detection levels which are currently selected;
and the source service node selects at least one SFCOAM detection level from the multiple SFCOAM detection levels.
3. The method of claim 2, wherein the plurality of SFCOAM detection levels comprises at least one of:
SFCOAM detection hierarchy between different service nodes experienced by a service function chain;
SFCOAM detection hierarchy between service function forwarders SFF on different service nodes experienced by the service function chain;
SFCOAM detection hierarchy between service functions SF managed by SFFs on different service nodes experienced by the service function chain.
4. The method of claim 1, wherein the SFCOAM detection level information is encapsulated in specific bits of a service function header NSH or the SFCOAM detection level information is encapsulated in the remaining headers except for the NSH.
5. The method according to any of claims 1 to 4, wherein the source service node is one of a traffic classifier or a service node on a traffic function chain.
6. The method according to any of claims 1 to 4, wherein the destination service node is a remaining service node or a combination of service nodes on a service function chain other than the source service node.
7. The method according to any of claims 1 to 4, wherein the SFCOAM detection packet comprises one of the following types: connectivity detection messages, Ping messages and Trace messages.
8. A processing method for detecting hierarchical information is characterized by comprising the following steps:
a destination service node receives a service function chain SFC operation, management and maintenance OAM detection message from a source service node, wherein the SFCOAM detection message carries SFCOAM detection level information which is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes;
and the destination service node analyzes SFCOAM detection level information from the SFCOAM detection message and determines an SFCOAM response message to be fed back according to the SFCOAM detection level information.
9. The method of claim 8, wherein the destination service node determines that the SFCOAM response packet includes one of the following according to the SFCOAM detection level information:
when the SFCOAM detection level information is an SFCOAM detection level between different service nodes experienced by a service function chain, the destination service node directly processes the SFCOAM detection message, and after the SFCOAM detection message is processed, information carried in the SFCOAM response message includes at least one of the following: node information of the destination service node, connectivity information of the destination service node, and path information of the destination service node;
when the SFCOAM detection level information is an SFCOAM detection level between service function forwarders SFF on different service nodes experienced by the service function chain, the destination service node forwards the SFCOAM detection message to a service function forwarder SFF to process the SFCOAM message, and after the SFF finishes processing the SFCOAM message, information carried in the SFCOAM response message includes at least one of the following: the connectivity information of the SFF of the destination service node, the path information of the SFF and the service level protocol information of the SFF;
when the SFCOAM detection level information is an SFCOAM detection level between service functions SF respectively managed by different SFFs experienced by the service function chain, the destination service node forwards the SFCOAM detection message to the service function forwarder SFF for processing, and then forwards the SFCOAM detection message to the service function SF for processing, and after the processing is finished, information carried in the SFCOAM response message includes at least one of the following: service function information of the SF under the SFF management of the destination service node, connectivity information of the SF, path information of the SF and service level protocol information of the SF.
10. A processing apparatus for detecting hierarchical information, comprising:
the system comprises a determining module, a detecting module and a judging module, wherein the determining module is used for determining the operation, management and maintenance OAM detection level information of a service function chain SFC and packaging the SFCOAM detection level information in an SFCOAM detection message, and the SFCOAM detection level information is used for indicating that SFCOAM detection is carried out between peer entities belonging to the same level in different service nodes;
and the sending module is used for sending the SFCOAM detection message to the destination service node.
11. The apparatus of claim 10, wherein the determining module comprises:
the acquisition unit is used for acquiring various currently-alternative SFCOAM detection levels;
and the selection unit is used for selecting one SFCOAM detection level from the multiple SFCOAM detection levels.
12. The apparatus of claim 11, wherein the plurality of SFCOAM detection levels comprise at least one of:
SFCOAM detection hierarchy between different service nodes experienced by a service function chain;
SFCOAM detection hierarchy between service function forwarders SFF on different service nodes experienced by the service function chain;
SFCOAM detection hierarchy between service functions SF managed by SFFs on different service nodes experienced by the service function chain.
13. The apparatus of claim 10, wherein the SFCOAM detection level information is encapsulated in a specific bit of a service function header NSH or the SFCOAM detection level information is encapsulated in the remaining headers except for the NSH.
14. The apparatus according to any of claims 10 to 13, wherein the source service node is one of a traffic classifier or a service node on a traffic function chain.
15. The apparatus according to any of claims 10 to 13, wherein the destination service node is a remaining service node or a combination of service nodes on a service function chain other than the source service node.
16. The apparatus according to any of claims 10 to 13, wherein the SFCOAM detection packet comprises one of the following types: connectivity detection messages, Ping messages and Trace messages.
17. A processing apparatus for detecting hierarchical information, comprising:
a receiving module, configured to receive an operation, administration, and maintenance OAM detection packet of a service function chain SFC from a source service node, where the SFCOAM detection packet carries SFCOAM detection level information, and the SFCOAM detection level information is used to indicate that SFCOAM detection is performed between peer entities belonging to the same level in different service nodes;
and the processing module is used for analyzing SFCOAM detection level information from the SFCOAM detection message and determining an SFCOAM response message to be fed back according to the SFCOAM detection level information.
18. The apparatus of claim 17, wherein the processing module is configured to directly process the SFCOAM detection packet when the SFCOAM detection level information is an SFCOAM detection level between different service nodes experienced by a service function chain, and after the SFCOAM detection packet is processed, information carried in the SFCOAM response packet includes at least one of:
node information of the destination service node, connectivity information of the destination service node, and path information of the destination service node; or, when the SFCOAM detection level information is an SFCOAM detection level between SFFs on different service nodes experienced by the service function chain, forwarding the SFCOAM detection packet to the SFF to process the SFCOAM packet, and after the SFF finishes processing the SFCOAM packet, information carried in the SFCOAM response packet includes at least one of the following: the connectivity information of the SFF of the destination service node, the path information of the SFF and the service level protocol information of the SFF; or, when the SFCOAM detection level information is an SFCOAM detection level between service functions SF respectively managed by different SFFs experienced by the service function chain, forwarding the SFCOAM detection message to the SFF for processing, and then forwarding the SFCOAM detection message to the SF for processing, until the SFF and the SF finish processing the SFCOAM detection message, the information carried in the SFCOAM response message includes at least one of the following: service function information of the SF under the SFF management of the destination service node, connectivity information of the SF, path information of the SF and service level protocol information of the SF.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410559786.0A CN105515816B (en) | 2014-10-20 | 2014-10-20 | Processing method and device for detecting hierarchical information |
| PCT/CN2014/092070 WO2015184740A1 (en) | 2014-10-20 | 2014-11-24 | Method and device for processing detection hierarchy information |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410559786.0A CN105515816B (en) | 2014-10-20 | 2014-10-20 | Processing method and device for detecting hierarchical information |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105515816A true CN105515816A (en) | 2016-04-20 |
| CN105515816B CN105515816B (en) | 2019-12-31 |
Family
ID=54766011
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410559786.0A Expired - Fee Related CN105515816B (en) | 2014-10-20 | 2014-10-20 | Processing method and device for detecting hierarchical information |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN105515816B (en) |
| WO (1) | WO2015184740A1 (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108574582A (en) * | 2017-03-07 | 2018-09-25 | 中兴通讯股份有限公司 | Fault detection method and device |
| CN109120657A (en) * | 2017-06-23 | 2019-01-01 | 中兴通讯股份有限公司 | A kind of business collocation method and node |
| CN109218058A (en) * | 2017-07-06 | 2019-01-15 | 中国电信股份有限公司 | Acquisition methods, system and the computer readable storage medium of OAM Information |
| CN110493052A (en) * | 2019-08-22 | 2019-11-22 | 北京交大思诺科技股份有限公司 | A kind of safety computer platform communication construction of compatible different communication protocol |
| CN110557343A (en) * | 2018-05-31 | 2019-12-10 | 中国电信股份有限公司 | SFC service data forwarding method and SFC network system |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114363116A (en) * | 2018-04-08 | 2022-04-15 | 华为技术有限公司 | Method and device for monitoring service quality |
| CN114553727B (en) * | 2022-02-18 | 2024-08-09 | 网宿科技股份有限公司 | Data processing method and device based on content distribution network |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101425928A (en) * | 2008-11-29 | 2009-05-06 | 中兴通讯股份有限公司 | Processing method and apparatus for maintaining entity group hierarchy |
| CN102185711A (en) * | 2011-04-26 | 2011-09-14 | 中兴通讯股份有限公司 | Method and equipment for detecting link failure in hybrid network |
| CN102239669A (en) * | 2011-01-14 | 2011-11-09 | 华为技术有限公司 | Data forwarding method and router |
| JP2012205286A (en) * | 2011-03-28 | 2012-10-22 | Ntt Communications Kk | Network supervision device, network test method, path information management method and program |
| CN103109527A (en) * | 2010-09-15 | 2013-05-15 | 三星电子株式会社 | Digital broadcast transmitter, digital broadcast receiver, and methods for configuring and processing streams thereof |
| WO2013155696A1 (en) * | 2012-04-20 | 2013-10-24 | Telefonaktiebolaget L M Ericsson (Publ) | Method to do fast traffic switchover based on server layer status |
| US20140078884A1 (en) * | 2010-03-09 | 2014-03-20 | Juniper Networks, Inc. | Communicating network path and status information in multi-homed networks |
-
2014
- 2014-10-20 CN CN201410559786.0A patent/CN105515816B/en not_active Expired - Fee Related
- 2014-11-24 WO PCT/CN2014/092070 patent/WO2015184740A1/en active Application Filing
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101425928A (en) * | 2008-11-29 | 2009-05-06 | 中兴通讯股份有限公司 | Processing method and apparatus for maintaining entity group hierarchy |
| US20140078884A1 (en) * | 2010-03-09 | 2014-03-20 | Juniper Networks, Inc. | Communicating network path and status information in multi-homed networks |
| CN103109527A (en) * | 2010-09-15 | 2013-05-15 | 三星电子株式会社 | Digital broadcast transmitter, digital broadcast receiver, and methods for configuring and processing streams thereof |
| CN102239669A (en) * | 2011-01-14 | 2011-11-09 | 华为技术有限公司 | Data forwarding method and router |
| JP2012205286A (en) * | 2011-03-28 | 2012-10-22 | Ntt Communications Kk | Network supervision device, network test method, path information management method and program |
| CN102185711A (en) * | 2011-04-26 | 2011-09-14 | 中兴通讯股份有限公司 | Method and equipment for detecting link failure in hybrid network |
| WO2013155696A1 (en) * | 2012-04-20 | 2013-10-24 | Telefonaktiebolaget L M Ericsson (Publ) | Method to do fast traffic switchover based on server layer status |
Non-Patent Citations (1)
| Title |
|---|
| J.HALPERN, C.PIGNATARO: "draft-merged-sfc-architecture-02", 《HTTPS_TOOLS.IETF.ORG》 * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108574582A (en) * | 2017-03-07 | 2018-09-25 | 中兴通讯股份有限公司 | Fault detection method and device |
| CN108574582B (en) * | 2017-03-07 | 2022-05-13 | 中兴通讯股份有限公司 | Fault detection method and device |
| CN109120657A (en) * | 2017-06-23 | 2019-01-01 | 中兴通讯股份有限公司 | A kind of business collocation method and node |
| CN109120657B (en) * | 2017-06-23 | 2022-08-16 | 中兴通讯股份有限公司 | Service configuration method and node |
| CN109218058A (en) * | 2017-07-06 | 2019-01-15 | 中国电信股份有限公司 | Acquisition methods, system and the computer readable storage medium of OAM Information |
| CN110557343A (en) * | 2018-05-31 | 2019-12-10 | 中国电信股份有限公司 | SFC service data forwarding method and SFC network system |
| CN110493052A (en) * | 2019-08-22 | 2019-11-22 | 北京交大思诺科技股份有限公司 | A kind of safety computer platform communication construction of compatible different communication protocol |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2015184740A1 (en) | 2015-12-10 |
| CN105515816B (en) | 2019-12-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105515816B (en) | Processing method and device for detecting hierarchical information | |
| CN105577413B (en) | Operations, Administration and Maintenance OAM message processing method and processing device | |
| CN111953604B (en) | Method and device for providing business service for business flow | |
| CN103036809B (en) | For having the method and apparatus of the scalable network that active link utilizes | |
| US10554542B2 (en) | Label distribution method and device | |
| CN107465565B (en) | Link test method and apparatus and system | |
| CN105577416B (en) | Service function chain operation, management and maintenance method and node equipment | |
| CN111886833A (en) | Control message redirection mechanism for SDN control channel failures | |
| EP3211832B1 (en) | Fault detection method and device | |
| EP3934183B1 (en) | Service function chain sfc-based communication methods, and apparatuses | |
| CN111049752B (en) | Load balancing method and device for multiple transmission lines | |
| CN105376154A (en) | Progressive MAC address learning | |
| US10623278B2 (en) | Reactive mechanism for in-situ operation, administration, and maintenance traffic | |
| CN105723654A (en) | Optimized multicast routing in a clos-like network | |
| US10972381B2 (en) | Network operations reactive to operations data included in seamless bidirectional forwarding detection (S-BFD) packets | |
| CN111447095B (en) | Bidirectional forwarding detection switching method, bidirectional forwarding detection module and edge device | |
| CN110224916B (en) | Message processing method and device and message packaging method, device and system | |
| KR101802037B1 (en) | Method and system of transmitting oam message for service function chaining in software defined network environment | |
| CN106656786B (en) | Flow protection method and device | |
| CN111435948A (en) | Method for transmitting message in network and network equipment | |
| CN115842696A (en) | Communication method, apparatus and computer-readable storage medium | |
| EP3131344A1 (en) | Method and system for discovery of access aggregation points for bonding approaches in a telecommunication network | |
| CN111182016B (en) | PPPoE dialing message transmission method and device | |
| WO2023247996A1 (en) | Method and system to mitigate fault in a distributed system | |
| CN116866014A (en) | Communication method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20191231 Termination date: 20201020 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |