[go: up one dir, main page]

WO2016058245A1 - Procédé et appareil de traitement pour un message d'exploitation, d'administration et d'entretien (oam) - Google Patents

Procédé et appareil de traitement pour un message d'exploitation, d'administration et d'entretien (oam) Download PDF

Info

Publication number
WO2016058245A1
WO2016058245A1 PCT/CN2014/092178 CN2014092178W WO2016058245A1 WO 2016058245 A1 WO2016058245 A1 WO 2016058245A1 CN 2014092178 W CN2014092178 W CN 2014092178W WO 2016058245 A1 WO2016058245 A1 WO 2016058245A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
oam
sfc
udp
service function
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.)
Ceased
Application number
PCT/CN2014/092178
Other languages
English (en)
Chinese (zh)
Inventor
王翠
孟伟
赵俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ZTE Corp filed Critical ZTE Corp
Publication of WO2016058245A1 publication Critical patent/WO2016058245A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/34—Signalling channels for network management communication

Definitions

  • the present invention relates to the field of communications, and in particular to an operation, management, and maintenance (OAM) message processing method and apparatus.
  • OAM operation, management, and maintenance
  • the network edge Since the development of the data center network to the Overlay network, the network edge has become the demarcation point between the virtual network and the physical network, wherein the network edge can be Server or ToR, and possibly Gateway.
  • the network edge can be Server or ToR, and possibly Gateway.
  • Overlay technology does not solve all the problems.
  • Middleware in the data center, such as firewall/load balancer. These devices process data based on user services. If you traverse these devices through tunnels, it is obviously not feasible.
  • This deployment model of the data center requires that the virtual firewall/load balancer can be deployed arbitrarily in the network, that is, independent of the network topology.
  • the new question is how to handle traffic flexibly through a virtual firewall/load balancer? Service processing functions such as these virtual firewalls/load balancers are independent of the original network topology and are implemented by standard servers.
  • the service processing function such as the virtual firewall/load balancer/gateway is called a service function (Service Function, referred to as SF), and the traffic is processed through a series of SFs to form a service function chain (Service Function Chaining). , referred to as SFC).
  • the business function chain is an orderly arrangement of a series of abstract business functions.
  • the SFCs are not defined in the order of which SFFs and/or SFs are ordered when the specific service traffic is forwarded.
  • 1 is an exemplary diagram of an SFC in the related art. As shown in FIG. 1, solid lines and broken lines indicate two SFCs, sometimes called a service chain Service Chain. The following describes the framework of the SFC.
  • the SFC can be divided into the following components:
  • Service Overlay that is, Overlay technology that each service function node needs to communicate
  • GSCP Generic Service Control Plane
  • SC Service Classifier
  • Service function (referred to as SF), a component that performs business processing on data packets;
  • the Service Function Forwarder is responsible for forwarding between multiple internal SFs of the same service node. After the data packet of the overlay is encapsulated and decapsulated by the network forwarding device of the service node, the network packet header is encapsulated, decapsulated, and updated by the network service header (NSH).
  • NSH network service header
  • Network Forwarder which is responsible for forwarding between multiple SFFs of the same service node; and encapsulating and decapsulating the Overlay layer of data packets of the Overlay; and processing different service nodes at the same time Forwarding
  • Service Function Path (SFP).
  • Figure 3 is a schematic diagram of the service function path in the related art. As shown in Figure 3, the SFP starts from the classifier and passes through several ordered specific service function instances. , a business processing path to the destination. In some cases, the general service control platform GSCP does not know all the service function instances that pass through the path, such as the load sharing scenario or the service service level scenario. At this time, the abstract service function chain SFC and the real specific traffic forwarding are passed. A description of such a business function chain between paths formed by an ordered business instance, also referred to as a business function path. A service function chain may include multiple service function paths, and different service function paths correspond to different policies.
  • Control plane metadata (Dataplane Metadata), which is a major feature. Metadata allows each business function node to exchange information with each other to achieve certain business processing purposes.
  • the SFC can separate the network device service function and forwarding, thereby implementing independent operation and processing of the service function, and improving the forwarding performance of the network device.
  • OAM technology is a network transmission technology for network connectivity detection, fault location, and troubleshooting, and a trigger mechanism for providing protection switching when a fault occurs. It includes the Link Connectivity Verification (CV) mechanism, the Ping mechanism, and the Trace mechanism.
  • CV Link Connectivity Verification
  • Ping the Ping mechanism
  • Trace the Trace mechanism.
  • OAM OAM mechanism
  • Ethernet has an Ethernet OAM protocol
  • IP network has an IP OAM protocol
  • MPLS network has an MPLS OAM.
  • the IP Ping and IP Traceroute mechanisms in IP OAM are based on the ICMP protocol.
  • the IP ping implements the request request and the reply reply message by extending the type field of the ICMP protocol.
  • the IP Traceroute implements the Traceroute request request packet by modifying the TTL value in the IP Ping request message, and implements the Traceroute through the TTL overdue ICMP error message.
  • the response is replying to the message; however, there are two major problems with the ICMP bearer: 1.
  • the protocols involving the two IP layers are ICMPv4 and ICMPv6 respectively.
  • LSP ping and LSP Trace mechanisms of the MPLS OAM are based on the UDP protocol and use the destination port number 3503.
  • LSP Ping and LSP Trace are not used based on ICMP for different types of LSPs, such as IPv4 LDP LSPs, IPv6 LDP LSPs, IPv4 RSVP LSPs, IPv6 RSVP LSPs, and PW LSPs.
  • the Ping and Traceroute extensions of the mechanism are extended based on the UDP protocol.
  • FIG. 4 is a schematic diagram of a SFC OAM technology framework in the related art.
  • the technical framework of the SFC OAM is mainly used for diagnosing link status between service function chains or service functions.
  • FIG. 5 is a schematic diagram of the SFC OAM packet format 1 in the related art.
  • a field is reserved in the service function packet header NSH for marking
  • the OAM packet and the OAM packet type are shown in Figure 6.
  • Figure 6 is a schematic diagram of the SFC OAM packet format 2 in the related art.
  • the service function packet header NSH is pre-defined. A bit is reserved for the OAM packet.
  • the OAM packet is placed in a packet other than the NSH of the service function header.
  • the protocol packet which is the extension of the ICMP packet, or the extension of the UDP packet, or other.
  • the present invention provides a method and a device for processing, managing, and maintaining an OAM packet, so as to at least solve the problem that the SFC OAM packet content cannot be determined in the related art, and the protocol is carried based on the protocol.
  • a method for processing, managing, and maintaining an OAM packet including: determining, by the source service node, an OAM packet for sending on a service function chain SFC, where the OAM packet The payload of the Payload, the OAM packet header, and the service function packet header, where the OAM packet is carried by a predetermined SFC OAM network port number; the source service node will be carried in the predetermined SFC OAM network port.
  • the OAM packet on the number is sent to the destination service node on the SFC for processing.
  • the OAM packet adopts at least one of the following formats: a Payload, an OAM packet header, and a service function packet header, where the SFC OAM type is carried in the OAM packet header; the Payload and the OAM packet header.
  • a service function packet header where the SFC OAM type is carried in the service function packet header.
  • the SFC OAM packet carried by the UDP protocol includes at least one of the following: a UDP source port number, a UDP destination port number used to identify the SFC OAM packet port number, and a version number used to identify the SFC OAM packet.
  • Information that is randomly generated by the request packet information for identifying the time point at which the packet is sent, information for identifying the time point at which the packet is received, for requesting the TLV to be extended in the packet, or for responding to the packet
  • the method further includes: a response mode carried in the SFC OAM packet
  • the destination service node does not carry the IPv4/IPv6 UDP packet of the service function packet header, where the IPv4/IPv6 UDP packet carries the OAM report.
  • the document carries the processing result obtained after processing the OAM packet.
  • the source service node is a service classifier or one of the service nodes on the service function chain.
  • a method for processing, managing, and maintaining an OAM packet including: the destination service node receives an OAM message sent on a service function chain SFC, where the OAM message includes: The payload of the Payload, the OAM packet header, and the service function packet header, wherein the OAM packet is carried by a predetermined SFC OAM network port number; and the destination service node processes the received OAM packet.
  • the OAM packet adopts at least one of the following formats: a Payload, an OAM packet header, and a service function packet header, where the SFC OAM type is carried in the OAM packet header; the Payload and the OAM packet header.
  • a service function packet header where the SFC OAM type is carried in the service function packet header.
  • the SFC OAM packet carried by the UDP protocol includes at least one of the following: a UDP source port number, a UDP destination port number used to identify the SFC OAM packet port number, and a version number used to identify the SFC OAM packet.
  • Information that is randomly generated by the request packet information for identifying the time point at which the packet is sent, information for identifying the time point at which the packet is received, for requesting the TLV to be extended in the packet, or for responding to the packet
  • the method further includes: when the response mode carried in the SFC OAM packet is an IPv4/IPv6 user data protocol UDP packet, The IPv4/IPv6 UDP packet of the function packet header is sent to the source service node or the next hop service node that sends the OAM packet, and the SFC OAM packet is carried in the SFC OAM packet.
  • the response mode is the SFC OAM UDP packet
  • the processing result of the OAM packet processing is sent to the source service node or the next hop service node that sends the OAM packet through the SFC OAM UDP packet. .
  • the destination service node is a combination of the other service node or the multiple service nodes except the source service node on the service function chain.
  • an OAM message processing apparatus which is located in a source service node, and includes: a determining module, configured to determine an OAM message for sending on a service function chain SFC.
  • the OAM packet includes: a payload Payload, an OAM packet header, and a service function packet header, wherein the OAM packet is carried by a predetermined SFC OAM network port number; and the first sending module is configured to: The OAM packet that is carried on the predetermined SFC OAM network port number is sent to the destination service node on the SFC for processing.
  • the OAM packet adopts at least one of the following formats: a Payload, an OAM packet header, and a service function packet header, where the SFC OAM type is carried in the OAM packet header; the Payload and the OAM packet header.
  • a service function packet header where the SFC OAM type is carried in the service function packet header.
  • the SFC OAM packet carried by the UDP protocol includes at least one of the following: a UDP source port number, a UDP destination port number used to identify the SFC OAM packet port number, and a version number used to identify the SFC OAM packet.
  • Information that is randomly generated by the request packet information for identifying the time point at which the packet is sent, information for identifying the time point at which the packet is received, for requesting the TLV to be extended in the packet, or for responding to the packet
  • the apparatus further includes: a first receiving module, configured to receive, when the response mode carried in the SFC OAM packet is an IPv4/IPv6 user data protocol UDP packet, the destination service node does not carry a service function report.
  • the response mode is the SFC OAM UDP packet
  • the SFC OAM UDP packet sent by the destination service node is received, where the SFC OAM UDP packet carries the processing result obtained after processing the OAM packet.
  • the source service node is a service classifier or one of the service nodes on the service function chain.
  • an OAM packet processing apparatus which is located in a destination service node, and includes: a third receiving module, configured to receive an OAM packet sent on a service function chain SFC.
  • the OAM packet includes: a payload Payload, an OAM packet header, and a service function packet header, wherein the OAM packet is carried by a predetermined SFC OAM network port number; and the processing module is configured to receive the OAM The message is processed.
  • the OAM packet adopts at least one of the following formats: a Payload, an OAM packet header, and a service function packet header, where the SFC OAM type is carried in the OAM packet header; the Payload and the OAM packet header.
  • a service function packet header where the SFC OAM type is carried in the service function packet header.
  • the SFC OAM packet carried by the UDP protocol includes at least one of the following: a UDP source port number, a UDP destination port number used to identify the SFC OAM packet port number, and a version number used to identify the SFC OAM packet.
  • Information that is randomly generated by the request packet information for identifying the time point at which the packet is sent, information for identifying the time point at which the packet is received, for requesting the TLV to be extended in the packet, or for responding to the packet
  • the apparatus further includes: a second sending module, configured to: when the response mode carried in the SFC OAM packet is an IPv4/IPv6 user data protocol UDP packet, by using an IPv4/IPv6 UDP that does not carry a service function packet header The packet is sent to the source service node or the next hop service node that sends the OAM packet, and the third sending module is configured to be carried in the SFC OAM packet.
  • the response mode is the SFC OAM UDP packet
  • the processing result of the OAM packet processing is sent to the source service node or the next hop service node that sends the OAM packet by using the SFC OAM UDP packet.
  • the destination service node is a combination of the other service node or the multiple service nodes except the source service node on the service function chain.
  • the source service node determines the OAM message to be sent on the service function chain SFC, where the OAM message includes: a payload Payload, an OAM packet header, and a service function packet header, where the The OAM packet is carried by the predetermined SFC OAM network port number; the source service node sends the OAM packet that is carried on the predetermined SFC OAM network port number to the destination service node on the SFC for processing.
  • the problem that the SFC OAM message content cannot be determined and the protocol is carried according to the protocol is solved, and the effect of determining a complete SFC OAM message and improving the SFC OAM scalability is achieved.
  • FIG. 1 is an exemplary diagram of an SFC in the related art
  • FIG. 2 is a schematic diagram of a packet format of a service function packet header in the related art
  • FIG. 3 is a schematic diagram of a service function path in the related art
  • FIG. 4 is a schematic diagram of a SFC OAM technology framework in the related art
  • FIG. 5 is a schematic diagram of a format 1 of an SFC OAM message in the related art
  • FIG. 6 is a schematic diagram of a second format of an SFC OAM packet in the related art
  • FIG. 7 is a flowchart of a method 1 for processing, managing, and maintaining an OAM packet according to an embodiment of the present invention
  • FIG. 8 is a flowchart of a method 2 for processing, managing, and maintaining an OAM packet according to an embodiment of the present invention
  • FIG. 9 is a structural block diagram of an apparatus for processing, managing, and maintaining an OAM message according to an embodiment of the present invention.
  • FIG. 10 is a block diagram showing a preferred structure of an OAM message processing apparatus 1 for operating, managing, and maintaining according to an embodiment of the present invention
  • FIG. 11 is a structural block diagram of an operation, management, and maintenance OAM message processing apparatus 2 according to an embodiment of the present invention.
  • FIG. 12 is a block diagram showing a preferred structure of an operation, management, and maintenance OAM message processing apparatus 2 according to an embodiment of the present invention.
  • FIG. 13 is a schematic diagram of a packet format of a UDP protocol carrying an SFC OAM packet according to an embodiment of the present invention
  • FIG. 14 is a schematic diagram of a format of a complete SFC OAM packet based on a UDP bearer after an Overlay encapsulation according to an embodiment of the present invention
  • FIG. 15 is a schematic diagram of a packet format for implementing an SFC ping function according to an embodiment of the present invention.
  • FIG. 16 is a schematic diagram of implementing an SFC Trace function according to an embodiment of the present invention.
  • FIG. 7 is a flowchart of a method for processing, managing, and maintaining an OAM packet according to an embodiment of the present invention. The process includes the following steps:
  • Step S702 the source service node determines an OAM message to be sent on the service function chain SFC, where the OAM message includes: a payload, a OAM packet header, and a service function packet header, where the OAM packet is scheduled.
  • SFC OAM network port number bearer
  • Step S704 The source service node sends the OAM packet that is carried on the predetermined SFC OAM network port number to the destination service node on the SFC for processing.
  • an OAM packet is determined, and the OAM packet is carried by the predetermined SFC OAM network port number, and the determined OAM packet is sent to the destination service node, and the SFC OAM report cannot be determined in the related technology.
  • the content of the text, and the question of what protocol is used to carry the message achieves the effect of determining a complete SFC OAM message and improving the scalability of the SFC OAM.
  • the foregoing OAM packet may be in a plurality of formats, for example, at least one of the following formats: a Payload, an OAM packet header, and a service function packet header, where the SFC OAM type is carried in the OAM packet header; the Payload and the OAM packet
  • the header of the service function is the header of the service function.
  • the SFC OAM type is carried in the service function header.
  • the protocol for carrying the SFC OAM packet may be multiple.
  • the following uses the UDP protocol as an example.
  • the SFC OAM packet carried by the UDP protocol may include at least one of the following: a UDP source port number, a UDP destination port number for identifying the SFC OAM packet port number, and version information for identifying the version number of the SFC OAM packet.
  • the packet type information used to identify the SFC OAM packet, the response mode information used to identify the response packet, the return coding information used to identify the cause of the fault, the frequency information used to identify the frequency of the packet transmission, and the request message The information randomly generated by the text, the information used to identify the time point of the message transmission, the information used to identify the time point of the message reception, the TLV to be used in the request message, or the identifier in the response message.
  • the source service node may be sent according to the response mode carried in the SFC OAM packet.
  • Different response messages as exemplified below.
  • the response mode carried in the SFC OAM packet is the IPv4/IPv6 user data protocol UDP packet
  • the IPv4/IPv6 UDP packet of the service function packet header is not received by the destination service node, where the IPv4/IPv6 UDP packet is received.
  • the SFC OAM UDP packet sent by the destination service node is received, and the SFC OAM UDP packet sent by the destination service node is received, for example, when the SFC OAM packet carries the SFC OAM UDP packet.
  • the UDP packet carries the processing result obtained after processing the OAM packet.
  • the response mode carried in the SFC OAM packet is not replied, the response packet sent by the destination service node is not received.
  • the source service node is a service classifier or one of the service nodes on the service function chain.
  • FIG. 8 is a flowchart of a second method for processing, managing, and maintaining an OAM packet according to an embodiment of the present invention. The process includes the following steps:
  • the destination service node receives the OAM packet sent by the service function chain SFC, where the OAM packet includes: a payload Payload, an OAM packet header, and a service function packet header, where the OAM packet adopts a predetermined SFC OAM.
  • Network port number bearer
  • Step S804 The destination service node processes the received OAM packet.
  • the OAM packet sent by the SFC OAM network port number sent by the SFC is received, and the received OAM packet is processed, and the SFC OAM packet content cannot be determined in the related art. And the problem of what protocol is used to carry the message, thereby achieving the effect of determining a complete SFC OAM message and improving the scalability of the SFC OAM.
  • the OAM packet After receiving the OAM packet that is sent by the SFC and using the predetermined SFC OAM network port number, the OAM packet is decapsulated, and the port number in the packet is found to be an SFC OAM packet. The OAM packet is processed.
  • the OAM packet can be in multiple formats, for example, at least one of the following formats: a Payload, an OAM packet header, and a service function packet header, where the SFC OAM type is carried in the OAM packet header; Payload, OAM A packet header and a service function packet header, where the SFC OAM type is carried in the service function packet header.
  • the SFC OAM packet can be carried in multiple protocols, and is described below by being carried in the UDP protocol.
  • the SFC OAM packet that is carried by the UPD protocol may include at least one of the following: a UDP source port number, a UDP destination port number used to identify the SFC OAM packet port number, and is used to identify the SFC OAM.
  • Frequency information information for requesting packet random generation, information for identifying the time point at which the message is sent, information for identifying the time point at which the message is received, for requesting the TLV to be extended in the message, or A TLV for identifying the service function link information obtained in the response message, and padding field information for identifying the padding field.
  • the response packet sent by the SFC OAM packet may be sent to the source service node according to the response mode.
  • the response mode carried in the SFC OAM packet is the IPv4/IPv6 user data protocol UDP packet
  • the processing result of the OAM packet processing is sent to the IPv4/IPv6 UDP packet without the service function packet header.
  • the source service node or the next hop service node of the OAM packet for example, when the response mode carried in the SFC OAM packet is SFC OAM UDP packet, the OAM packet processing is processed through the SFC OAM UDP packet.
  • the result is sent to the source service node or the next hop service node that sends the OAM message.
  • the destination service node does not need to send a response packet after receiving the OAM packet.
  • the destination service node is a combination of the other service node or the plurality of service nodes except the source service node on the service function chain.
  • an OAM packet processing device is also provided, which is used to implement the foregoing embodiments and preferred embodiments, and details are not described herein.
  • the term "module” may implement a combination of software and/or hardware of a predetermined function.
  • the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • FIG. 9 is a structural block diagram of an apparatus for processing, managing, and maintaining an OAM packet according to an embodiment of the present invention. As shown in FIG. 9, the apparatus is located in a source service node, and includes: a determining module 92 and a first sending module 94. The device will be described below.
  • the determining module 92 is configured to determine an OAM packet to be sent on the service function chain SFC, where the OAM packet includes: a payload Payload, an OAM packet header, and a service function packet header, where the OAM packet adopts a predetermined The SFC OAM network port number bearer; the first sending module 94 is connected to the determining module 92, and is configured to send the OAM packet that is carried on the predetermined SFC OAM network port number to the destination service node on the SFC for processing.
  • the OAM packet can be in multiple formats, for example, at least one of the following formats: a Payload, an OAM packet header, and a service function packet header, where the SFC OAM type is carried in the OAM packet header; Payload, OAM A packet header and a service function packet header, where the SFC OAM type is carried in the service function packet header.
  • the SFC OAM packet carried by the UDP protocol may include at least one of the following: a UDP source port number, a UDP destination port number used to identify the SFC OAM packet port number, and a version number used to identify the SFC OAM packet.
  • Information randomly generated in the request packet information indicating the time point at which the packet is sent, information indicating the time point at which the packet is received, TLV to be used in the request packet, or response message
  • TLV TLV identifying the acquired service function link information
  • padding field information for identifying the padding field.
  • FIG. 10 is a block diagram showing a preferred structure of an OAM packet processing apparatus according to an embodiment of the present invention. As shown in FIG. 10, the apparatus includes at least one of the following, in addition to all the modules shown in FIG. The first receiving module 102 and the second receiving module 104 are described below.
  • the first receiving module 102 is connected to the first sending module 94, and is configured to receive the service function node without receiving the service function node when the response mode carried in the SFC OAM packet is the IPv4/IPv6 user data protocol UDP packet.
  • the IPv4/IPv6 UDP packet wherein the IPv4/IPv6 UDP packet carries the processing result obtained after processing the OAM packet;
  • the second receiving module 104 is connected to the first sending module 94 and configured to be in the SFC OAM packet.
  • the SFC OAM UDP packet is received, the SFC OAM UDP packet is received by the destination service node.
  • the SFC OAM UDP packet carries the processing result obtained after the OAM packet is processed.
  • the source service node is a service classifier or one of the service nodes on the service function chain.
  • FIG. 11 is a structural block diagram of an operation, management, and maintenance OAM packet processing apparatus 2 according to an embodiment of the present invention. As shown in FIG. 11, the apparatus is located in a destination service node, and includes: a third receiving module 112 and a processing module 114. The device will be described below.
  • the third receiving module 112 is configured to receive the OAM packet sent by the service function chain SFC, where the OAM packet includes: a payload Payload, an OAM packet header, and a service function packet header, where the OAM packet adopts a predetermined The SFC OAM network port number bearer; the processing module 114 is connected to the third receiving module 112, and configured to process the received OAM message.
  • the OAM packet may be in at least one of the following formats: a Payload, an OAM packet header, and a service function packet header, where the SFC OAM type is carried in the OAM packet header; the Payload, the OAM packet header, and the service function.
  • the packet header in which the SFC OAM type is carried in the service function packet header.
  • the SFC OAM packet carried by the UDP protocol includes at least one of the following: a UDP source port number, a UDP destination port number used to identify the SFC OAM packet port number, and is used to identify the SFC OAM packet.
  • the frequency information the information used to randomly generate the request packet, the information used to identify the time point at which the message is sent, the information used to identify the time point of the message reception, the TLV to be used in the request message, or A TLV for identifying the obtained service function link information in the response message, and padding field information for identifying the padding field.
  • FIG. 12 is a block diagram showing a preferred structure of an operation, management, and maintenance OAM message processing apparatus 2 according to an embodiment of the present invention. As shown in FIG. 12, the apparatus includes at least one of the following, in addition to all the modules shown in FIG. The second transmitting module 122 and the third transmitting module 124 are described below.
  • the second sending module 122 is connected to the processing module 114, and is configured to pass the IPv4/IPv6 UDP packet that does not carry the service function packet header when the response mode carried in the SFC OAM packet is the IPv4/IPv6 user data protocol UDP packet.
  • the processing result of the OAM packet processing is sent to the source service node or the next hop service node that sends the OAM packet.
  • the third sending module 124 is connected to the processing module 114 and configured to be carried in the SFC OAM packet. When the response mode is SFC OAM UDP packet, the SFC OAM UDP packet is used to send the OAM packet processing result to the source service node or the next hop service node that sends the OAM packet.
  • the destination service node is a combination of the other service node or the plurality of service nodes except the source service node on the service function chain.
  • FIG. 13 is a schematic diagram of a packet format of a UDP protocol carrying an SFC OAM packet according to an embodiment of the present invention, as shown in FIG.
  • Source Port identifies the UDP source port number.
  • Destination Port identifies the UDP destination port number.
  • a new port number is defined to carry the SFC OAM packet.
  • Version Number identifies the version number of the SFC OAM packet.
  • Message Type identifies the SFC OAM packet type, including the Ping Request packet, the ping reply packet, the connectivity request packet, and the connectivity Reply packet.
  • Reply Mode identifies the response mode of the response packet.
  • the response packet can respond with a normal IPv4/IPv6UDP packet or send a message response through the service function path SFP.
  • the response packet carries the number of the fault (for example, the request packet is incorrect, the TLV is not recognized, the service function is abnormal, etc.); the field in the request packet is 0;
  • Sender’s Handle The request message is randomly generated; the field in the response message is consistent with the request message;
  • Timestamp Sent identifies the time point at which the message is sent.
  • Timestamp Received indicates the time point at which the message is received.
  • the SFP information is included in the service function header and is carried to the last hop service node along the path. Therefore, the SFC ping or SFC Trace request packet may not carry the field.
  • the field needs to obtain the service function link information or the service function related information of the service function chain (for example, bandwidth information, resource information, delay information, etc.)
  • the TLV field needs to be carried in response to the initiator of the SFC Trace. Different types correspond to different information.
  • Padding identifies the padding field to meet the byte requirements required by the message
  • FIG. 14 is a schematic diagram of a format of a complete SFC OAM packet based on UDP bearer after Overlay encapsulation, as shown in FIG. 14 .
  • the service function chain of the embodiment based on the SFC ping function includes: SF1 -> SF2 -> SF3; wherein the Overlay network is an IP network.
  • FIG. 15 is a schematic diagram of a packet format for implementing the SFC ping function according to an embodiment of the present invention. As shown in Figure 15, the SFC OAM dedicated port number is used in the UDP header, and the packet type in the SFC ping request packet is a request packet. Text, the response mode is configured as above. In this embodiment, implementing the Ping function includes the following steps:
  • the Classifier sends the OAM packet in Figure 15 and forwards the packet to the first hop service node 1 of the service function path;
  • the service node 1 decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF1.
  • the SFF1 determines that the message is an OAM ping protocol packet, and then forwards the packet to the SFC OAM protocol module.
  • the SFC OAM protocol module invokes the first hop service function SF1 to check whether it is running normally, and if yes, forwards the packet back to SFF1;
  • SFF1 forwards the packet to the service node 1, and the service node 1 performs Overlay encapsulation on the packet, and forwards the packet to the next hop service node 2;
  • the ping response message is configured to carry the service function fault information; and the response message is forwarded to SFF1;
  • SFF1 forwards the corresponding packet to the service node 1, and the service node 1 performs Overlay encapsulation on the packet, and forwards the packet to the Classifier.
  • the service node 2 receives the packet, first decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF2.
  • the SFF2 determines that the packet is an OAM protocol packet, and then forwards the packet to the SFC OAM protocol module. ;
  • the SFC OAM protocol module invokes the second hop service function SF2 to check whether it is running normally. If yes, the packet is forwarded back to SFF2.
  • SFF2 forwards the packet to the service node 2, and the service node 2 performs Overlay encapsulation on the packet, and forwards the packet to the next hop service node 3;
  • the ping response message is configured to carry the service function fault information; and the response message is forwarded to the SFF2;
  • SFF2 forwards the corresponding packet to the service node 2, and the service node 2 performs Overlay encapsulation on the packet, forwards the packet to the service node 1 along the reverse path, and then forwards the packet to the Classifier;
  • the service node 3 receives the packet, first decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF3.
  • the SFF3 determines that this is an OAM protocol packet and is the last hop of the service function path. , continue to forward to the SFC OAM protocol module processing;
  • the SFC OAM protocol module invokes the third hop service function SF3 to check whether it is running normally. If yes, construct a Ping response message and forward the message back to SFF3; if not, construct a Ping response message to carry Faulty service function fault information; and forwards the packet back to SFF3;
  • SFF3 forwards the packet to the service node 3, and the service node 3 performs Overlay encapsulation on the packet, forwards the packet to the service node 2 and the service node 1 along the reverse path, and then forwards the packet to the Classifier;
  • the Classifier After receiving the Ping response packet, the Classifier displays to the operator whether the Ping succeeds. If it is not successful, the reason for the operator failure is displayed.
  • the service function chain of the specific embodiment based on the SFC Trace function includes: SF1--->SF2--->SF3, where the Overlay network is an IP network.
  • FIG. 16 is a schematic diagram of implementing the SFC Trace function according to the embodiment of the present invention, as shown in FIG. 16 , wherein the UDP header uses the SFC OAM dedicated port number, and the SFC Trace request packet has the packet type as the request packet.
  • the response mode is configured as above; the embodiment includes the following steps:
  • the Classifier sends the OAM packet in FIG. 16 and sets the TTL field in the packet to 1, and forwards the packet to the first hop service node 1 of the service function path;
  • the service node 1 decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF1.
  • the SFF1 determines that the packet is an OAM Trace protocol packet and the TTL is 1, and then forwards the packet to the SFC OAM protocol module.
  • the SFC OAM protocol module invokes the first hop service function SF1 to check whether it is in normal operation. If yes, the service information, the resource information, and the delay information of the SF1 are obtained, and are encapsulated in the TLV of the response packet, and the packet is encapsulated. Forwarded to SFF1; if not, constructs a response packet, carries the service function fault information, and forwards the packet back to SFF1;
  • SFF1 forwards the packet to the service node 1, and the service node 1 performs Overlay encapsulation on the packet, and forwards the packet to the Classifier along the IP path.
  • the classifier receives the corresponding packet of the first hop service node, and displays the message to the operator whether the trace is successful. If the success is successful, the information is obtained.
  • the classifier constructs the SFC Trace packet with the TTL of 2 and forwards the packet to the service.
  • the service node 1 receives the packet, first decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF1.
  • the SFF1 determines that the packet is an OAM protocol packet, and then forwards the packet to the SFC OAM protocol module. At the same time, SFF1 will decrement the TTL value in the message by one;
  • the SFC OAM protocol module invokes the first hop service function SF1 to check whether it is running normally. If yes, the packet is forwarded back to SFF1.
  • SFF1 forwards the packet to the service node 1, and the service node 1 performs Overlay encapsulation on the packet, and forwards the packet to the next hop service node 2;
  • the service node 2 receives the packet, first decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF2.
  • the SFF2 determines that the packet is an OAM protocol packet and the TTL is 1. SFC OAM protocol module processing;
  • the SFC OAM protocol module invokes the second hop service function SF2 to check whether it is running normally. If yes, the service information, the resource information, and the delay information of the SF2 are obtained, and are encapsulated in the TLV of the response packet, and the packet is sent. Forwarding to SFF2; if not, constructing a response packet, carrying the service function fault information, and forwarding the packet back to SFF2;
  • the SFF2 forwards the packet to the service node 2, and the service node 2 performs Overlay encapsulation on the packet, and forwards the packet to the Classifier along the IP path.
  • the classifier receives the corresponding packet of the second hop service node, and displays the message to the operator whether the trace is successful. If the success is successful, the information is obtained.
  • the classifier constructs the SFC Trace packet with the TTL of 3 and forwards the packet to the service.
  • the service node 1 receives the packet, first decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF1.
  • the SFF1 determines that the packet is an OAM protocol packet, and then forwards the packet to the SFC OAM protocol module. At the same time, SFF1 will decrement the TTL value in the message by one;
  • the protocol module invokes the first hop service function SF1 to check whether it is running normally, and if yes, forwards the packet back to SFF1;
  • SFF1 forwards the packet to the service node 1, and the service node 1 performs Overlay encapsulation on the packet, and forwards the packet to the next hop service node 2;
  • the service node 2 receives the packet, first decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF2.
  • the SFF2 determines that the packet is an OAM protocol packet, and then forwards the packet to the SFC OAM protocol module. At the same time, SFF2 will decrement the TTL value in the message by one;
  • the protocol module invokes the first hop service function SF2 to check whether it is running normally. If yes, the packet is forwarded back to SFF2.
  • SFF2 forwards the packet to the service node 2, and the service node 2 performs Overlay encapsulation on the packet, and forwards the packet to the next hop service node 3;
  • the service node 3 receives the packet, first decapsulates the Overlay layer, and forwards the packet carrying the SFC service function header to the SFF3.
  • the SFF3 determines that the packet is an OAM protocol packet and the TTL is 1. SFC OAM protocol module processing;
  • the protocol module invokes the third hop service function SF3 to check whether it is running normally. If yes, the SF3 service information, resource information, and delay information are obtained, encapsulated in the TLV of the response packet, and the packet is forwarded back. SFF3; if not, construct a response message, carry the service function fault information, and forward the message back to SFF3;
  • SFF3 forwards the packet to the service node 3, and the service node 3 performs Overlay encapsulation on the packet, and forwards the packet to the Classifier along the IP path.
  • the classifier receives the corresponding packet of the third hop service node, and displays to the operator whether the trace is successful. If successful, the obtained information is displayed; if the sending is unsuccessful, the reason for the failure is displayed.
  • modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.
  • the embodiment of the present invention provides a method and an apparatus for processing, managing, and maintaining an OAM packet, and solves the problem that the SFC OAM packet content cannot be determined in the related art, and the protocol is carried based on the protocol. Achieved a complete SFC OAM message and improved SFC OAM scalability.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé et un appareil de traitement pour un message d'exploitation, d'administration et d'entretien (OAM). Le procédé comprend les opérations suivantes : un nœud de service d'extrémité source détermine un message OAM à envoyer sur un chaînage de fonction de service (SFC), le message OAM comprenant des données utiles de charge, un en-tête de message OAM et un en-tête de message de fonction de service, le message OAM étant acheminé par un nombre de ports de réseau OAM de SFC prédéterminé ; le nœud de service d'extrémité source envoie le message OAM qui est acheminé sur le nombre de ports de réseau OAM de SFC prédéterminé à un nœud de service de destination sur le SFC pour un traitement. Au moyen de la présente invention, les problèmes dans l'état antérieur de la technique selon lesquels le contenu du message OAM de SFC ne peut pas être déterminé et un protocole sur la base duquel le message est acheminé ne peut pas être déterminé, peuvent être résolus, et les effets de détermination d'un message OAM de SFC complet et d'amélioration de l'extensibilité OAM de SFC sont en outre obtenus.
PCT/CN2014/092178 2014-10-17 2014-11-25 Procédé et appareil de traitement pour un message d'exploitation, d'administration et d'entretien (oam) Ceased WO2016058245A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410555236.1 2014-10-17
CN201410555236.1A CN105577413B (zh) 2014-10-17 2014-10-17 操作、管理和维护oam报文处理方法及装置

Publications (1)

Publication Number Publication Date
WO2016058245A1 true WO2016058245A1 (fr) 2016-04-21

Family

ID=55746008

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2014/092178 Ceased WO2016058245A1 (fr) 2014-10-17 2014-11-25 Procédé et appareil de traitement pour un message d'exploitation, d'administration et d'entretien (oam)

Country Status (2)

Country Link
CN (1) CN105577413B (fr)
WO (1) WO2016058245A1 (fr)

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3273640A1 (fr) * 2016-07-21 2018-01-24 Cisco Technology, Inc. Sélection de liaison pour la communication avec une grappe de fonction de service
US10148577B2 (en) 2014-12-11 2018-12-04 Cisco Technology, Inc. Network service header metadata for load balancing
US10187306B2 (en) 2016-03-24 2019-01-22 Cisco Technology, Inc. System and method for improved service chaining
US10218593B2 (en) 2016-08-23 2019-02-26 Cisco Technology, Inc. Identifying sources of packet drops in a service function chain environment
US10225270B2 (en) 2016-08-02 2019-03-05 Cisco Technology, Inc. Steering of cloned traffic in a service function chain
US10225187B2 (en) 2017-03-22 2019-03-05 Cisco Technology, Inc. System and method for providing a bit indexed service chain
US10237379B2 (en) 2013-04-26 2019-03-19 Cisco Technology, Inc. High-efficiency service chaining with agentless service nodes
US10257033B2 (en) 2017-04-12 2019-04-09 Cisco Technology, Inc. Virtualized network functions and service chaining in serverless computing infrastructure
US10320664B2 (en) 2016-07-21 2019-06-11 Cisco Technology, Inc. Cloud overlay for operations administration and management
US10333855B2 (en) 2017-04-19 2019-06-25 Cisco Technology, Inc. Latency reduction in service function paths
US10397271B2 (en) 2017-07-11 2019-08-27 Cisco Technology, Inc. Distributed denial of service mitigation for web conferencing
US10419550B2 (en) 2016-07-06 2019-09-17 Cisco Technology, Inc. Automatic service function validation in a virtual network environment
US10541893B2 (en) 2017-10-25 2020-01-21 Cisco Technology, Inc. System and method for obtaining micro-service telemetry data
US10554689B2 (en) 2017-04-28 2020-02-04 Cisco Technology, Inc. Secure communication session resumption in a service function chain
US10666612B2 (en) 2018-06-06 2020-05-26 Cisco Technology, Inc. Service chains for inter-cloud traffic
US10673698B2 (en) 2017-07-21 2020-06-02 Cisco Technology, Inc. Service function chain optimization using live testing
USRE48131E1 (en) 2014-12-11 2020-07-28 Cisco Technology, Inc. Metadata augmentation in a service function chain
US10735275B2 (en) 2017-06-16 2020-08-04 Cisco Technology, Inc. Releasing and retaining resources for use in a NFV environment
US10791065B2 (en) 2017-09-19 2020-09-29 Cisco Technology, Inc. Systems and methods for providing container attributes as part of OAM techniques
US10798187B2 (en) 2017-06-19 2020-10-06 Cisco Technology, Inc. Secure service chaining
US10884807B2 (en) 2017-04-12 2021-01-05 Cisco Technology, Inc. Serverless computing and task scheduling
US10931793B2 (en) 2016-04-26 2021-02-23 Cisco Technology, Inc. System and method for automated rendering of service chaining
US11018981B2 (en) 2017-10-13 2021-05-25 Cisco Technology, Inc. System and method for replication container performance and policy validation using real time network traffic
US11063856B2 (en) 2017-08-24 2021-07-13 Cisco Technology, Inc. Virtual network function monitoring in a network function virtualization deployment
CN114143380A (zh) * 2022-01-04 2022-03-04 烽火通信科技股份有限公司 解决SRv6尾节点掉电场景OAM和业务不一致的方法和系统
CN115766536A (zh) * 2022-11-11 2023-03-07 北京百度网讯科技有限公司 一种服务链探测系统、方法、装置及电子设备

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3468117B1 (fr) * 2016-07-01 2023-05-24 Huawei Technologies Co., Ltd. Procédé, dispositif et système de réacheminement de paquets basés sur le chaînage de fonctions de service (sfc)
CN111884934B (zh) * 2016-07-01 2021-07-09 华为技术有限公司 业务功能链sfc中用于转发报文的方法、装置和系统
CN108512675B (zh) * 2017-02-25 2021-06-15 华为技术有限公司 一种网络诊断的方法、装置、控制节点和网络节点
CN109218058B (zh) * 2017-07-06 2021-09-14 中国电信股份有限公司 Oam信息的获取方法、系统及计算机可读存储介质
CN115733720A (zh) * 2019-11-14 2023-03-03 华为技术有限公司 发送报文、接收报文以进行oam的方法、装置及系统
CN113497758B (zh) * 2020-04-03 2023-02-14 华为技术有限公司 服务执行方法、装置及系统
CN115225732A (zh) * 2021-04-21 2022-10-21 华为技术有限公司 一种操作维护管理oam检测方法及装置
CN115733767A (zh) * 2021-09-01 2023-03-03 华为技术有限公司 路径故障检测方法、装置、系统、网络设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102224709A (zh) * 2011-04-20 2011-10-19 华为技术有限公司 Ip承载网性能监控的方法及设备
CN103580894A (zh) * 2012-07-31 2014-02-12 华为技术有限公司 操作、管理和维护oam配置的方法、设备及系统
CN103716172A (zh) * 2012-09-28 2014-04-09 中兴通讯股份有限公司 一种基于多协议标签交换的oam方法及装置
CN104052623A (zh) * 2014-06-25 2014-09-17 成都广达电子股份有限公司 以太网无源光网络中的报文处理方法和报文处理系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102185780B (zh) * 2011-05-12 2015-09-16 中兴通讯股份有限公司 Oam报文处理方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102224709A (zh) * 2011-04-20 2011-10-19 华为技术有限公司 Ip承载网性能监控的方法及设备
CN103580894A (zh) * 2012-07-31 2014-02-12 华为技术有限公司 操作、管理和维护oam配置的方法、设备及系统
CN103716172A (zh) * 2012-09-28 2014-04-09 中兴通讯股份有限公司 一种基于多协议标签交换的oam方法及装置
CN104052623A (zh) * 2014-06-25 2014-09-17 成都广达电子股份有限公司 以太网无源光网络中的报文处理方法和报文处理系统

Cited By (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10237379B2 (en) 2013-04-26 2019-03-19 Cisco Technology, Inc. High-efficiency service chaining with agentless service nodes
US10148577B2 (en) 2014-12-11 2018-12-04 Cisco Technology, Inc. Network service header metadata for load balancing
USRE48131E1 (en) 2014-12-11 2020-07-28 Cisco Technology, Inc. Metadata augmentation in a service function chain
US10187306B2 (en) 2016-03-24 2019-01-22 Cisco Technology, Inc. System and method for improved service chaining
US10812378B2 (en) 2016-03-24 2020-10-20 Cisco Technology, Inc. System and method for improved service chaining
US10931793B2 (en) 2016-04-26 2021-02-23 Cisco Technology, Inc. System and method for automated rendering of service chaining
US10419550B2 (en) 2016-07-06 2019-09-17 Cisco Technology, Inc. Automatic service function validation in a virtual network environment
US10218616B2 (en) 2016-07-21 2019-02-26 Cisco Technology, Inc. Link selection for communication with a service function cluster
US10320664B2 (en) 2016-07-21 2019-06-11 Cisco Technology, Inc. Cloud overlay for operations administration and management
EP3273640A1 (fr) * 2016-07-21 2018-01-24 Cisco Technology, Inc. Sélection de liaison pour la communication avec une grappe de fonction de service
US10225270B2 (en) 2016-08-02 2019-03-05 Cisco Technology, Inc. Steering of cloned traffic in a service function chain
US10778551B2 (en) 2016-08-23 2020-09-15 Cisco Technology, Inc. Identifying sources of packet drops in a service function chain environment
US10218593B2 (en) 2016-08-23 2019-02-26 Cisco Technology, Inc. Identifying sources of packet drops in a service function chain environment
US10225187B2 (en) 2017-03-22 2019-03-05 Cisco Technology, Inc. System and method for providing a bit indexed service chain
US10778576B2 (en) 2017-03-22 2020-09-15 Cisco Technology, Inc. System and method for providing a bit indexed service chain
US10257033B2 (en) 2017-04-12 2019-04-09 Cisco Technology, Inc. Virtualized network functions and service chaining in serverless computing infrastructure
US10938677B2 (en) 2017-04-12 2021-03-02 Cisco Technology, Inc. Virtualized network functions and service chaining in serverless computing infrastructure
US10884807B2 (en) 2017-04-12 2021-01-05 Cisco Technology, Inc. Serverless computing and task scheduling
US10333855B2 (en) 2017-04-19 2019-06-25 Cisco Technology, Inc. Latency reduction in service function paths
US11102135B2 (en) 2017-04-19 2021-08-24 Cisco Technology, Inc. Latency reduction in service function paths
US10554689B2 (en) 2017-04-28 2020-02-04 Cisco Technology, Inc. Secure communication session resumption in a service function chain
US12028378B2 (en) 2017-04-28 2024-07-02 Cisco Technology, Inc. Secure communication session resumption in a service function chain preliminary class
US11539747B2 (en) 2017-04-28 2022-12-27 Cisco Technology, Inc. Secure communication session resumption in a service function chain
US11196640B2 (en) 2017-06-16 2021-12-07 Cisco Technology, Inc. Releasing and retaining resources for use in a NFV environment
US10735275B2 (en) 2017-06-16 2020-08-04 Cisco Technology, Inc. Releasing and retaining resources for use in a NFV environment
US10798187B2 (en) 2017-06-19 2020-10-06 Cisco Technology, Inc. Secure service chaining
US10397271B2 (en) 2017-07-11 2019-08-27 Cisco Technology, Inc. Distributed denial of service mitigation for web conferencing
US11108814B2 (en) 2017-07-11 2021-08-31 Cisco Technology, Inc. Distributed denial of service mitigation for web conferencing
US11115276B2 (en) 2017-07-21 2021-09-07 Cisco Technology, Inc. Service function chain optimization using live testing
US10673698B2 (en) 2017-07-21 2020-06-02 Cisco Technology, Inc. Service function chain optimization using live testing
US11063856B2 (en) 2017-08-24 2021-07-13 Cisco Technology, Inc. Virtual network function monitoring in a network function virtualization deployment
US10791065B2 (en) 2017-09-19 2020-09-29 Cisco Technology, Inc. Systems and methods for providing container attributes as part of OAM techniques
US11018981B2 (en) 2017-10-13 2021-05-25 Cisco Technology, Inc. System and method for replication container performance and policy validation using real time network traffic
US11252063B2 (en) 2017-10-25 2022-02-15 Cisco Technology, Inc. System and method for obtaining micro-service telemetry data
US10541893B2 (en) 2017-10-25 2020-01-21 Cisco Technology, Inc. System and method for obtaining micro-service telemetry data
US11122008B2 (en) 2018-06-06 2021-09-14 Cisco Technology, Inc. Service chains for inter-cloud traffic
US11799821B2 (en) 2018-06-06 2023-10-24 Cisco Technology, Inc. Service chains for inter-cloud traffic
US10666612B2 (en) 2018-06-06 2020-05-26 Cisco Technology, Inc. Service chains for inter-cloud traffic
CN114143380A (zh) * 2022-01-04 2022-03-04 烽火通信科技股份有限公司 解决SRv6尾节点掉电场景OAM和业务不一致的方法和系统
CN114143380B (zh) * 2022-01-04 2023-06-09 烽火通信科技股份有限公司 解决SRv6尾节点掉电场景OAM和业务不一致的方法和系统
CN115766536A (zh) * 2022-11-11 2023-03-07 北京百度网讯科技有限公司 一种服务链探测系统、方法、装置及电子设备
CN115766536B (zh) * 2022-11-11 2024-08-27 北京百度网讯科技有限公司 一种服务链探测系统、方法、装置及电子设备

Also Published As

Publication number Publication date
CN105577413B (zh) 2019-09-10
CN105577413A (zh) 2016-05-11

Similar Documents

Publication Publication Date Title
CN105577413B (zh) 操作、管理和维护oam报文处理方法及装置
US10972391B2 (en) Full-path validation in segment routing
US20210273866A1 (en) Service Chain Fault Detection Method and Apparatus
US9917745B2 (en) Validation of chained network services
CN113411834B (zh) 报文处理方法、装置、设备及存储介质
US9497107B1 (en) Seamless path monitoring and rapid fault isolation using bidirectional forwarding detection in a network environment
EP3332511B1 (fr) Procédé et système pour une surveillance de chemin dans un système de réseautage défini par logiciel (sdn)
US8837300B2 (en) Managing trace requests over tunneled links
US8976682B2 (en) Connection verification for MPLS label switched paths and pseudowires
JP5992602B2 (ja) ＩＰｖ６ネットワークにおいてラベル配布プロトコル（ＬＤＰ）を使用するためのシステムおよび方法
US7746796B2 (en) Directed echo requests and reverse traceroute
US10063447B2 (en) Path-ping and ECMP-traceroute for IPV6 overlay virtualized networks
US8971195B2 (en) Querying health of full-meshed forwarding planes
CN108604997B (zh) 用于对差异化服务编码点(dscp)和显式拥塞通知(ecn)的监视进行配置的控制平面的方法和设备
CN105577416B (zh) 一种业务功能链操作、管理和维护方法及节点设备
JP6622922B2 (ja) ＤＳＣＰ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ）およびＥＣＮ（Ｅｘｐｌｉｃｉｔ Ｃｏｎｇｅｓｔｉｏｎ Ｎｏｔｉｆｉｃａｔｉｏｎ）をモニタリングするデータプレーンのための方法および装置
EP3382955A1 (fr) Procédé et dispositif de communication de chaînage de fonctions de service (sfc)
US20140293798A1 (en) Mpls-tp network and link trace method thereof
CN104852826B (zh) 一种环路检测方法及装置
WO2018210213A1 (fr) Procédé et dispositif de mise en œuvre d'un conditionnement ioam et support de stockage
CN106487572A (zh) 报文的处理方法及装置
WO2015184740A1 (fr) Procédé et dispositif de traitement d'informations de hiérarchie de détection
WO2016050177A1 (fr) Procédé de détermination de pmtu, dispositif et système de réseau
CN104185970B (zh) 发现转发信息以用于局部修复
CN109768874B (zh) 一种网络中配置变更的方法及装置

Legal Events

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

Ref document number: 14903921

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14903921

Country of ref document: EP

Kind code of ref document: A1