Automatic service function validation in a virtual network environment

• US 10,419,550 B2
• Filed: 07/06/2016
• Issued: 09/17/2019
• Est. Priority Date: 07/06/2016
• Status: Active Grant

• Current Assignee: Cisco Technology, Inc. (Cisco Systems, Inc.)
• Original Assignee: Cisco Technology, Inc. (Cisco Systems, Inc.)
• Inventors: Nainar, Nagendra Kumar, Asati, Rajiv, Pignataro, Carlos M.
• Primary Examiner(s): Christensen, Scott B
• Application Number:
  US15/203,759
• Publication Number:
  US 20180013841A1
• Time in Patent Office: 1,168 Days
• Field of Search: None
• CPC Class Codes: H04L 41/0866 Checking the configuration
• CPC Class Codes: H04L 43/0817 by checking functioning
• CPC Class Codes: H04L 43/10 Active monitoring, e.g. heartbeat, ping or trace-route
• CPC Class Codes: H04L 45/72 Routing based on the source address
• CPC Class Codes: H04L 67/10 in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46
• CPC Class Codes: H04L 67/51 Discovery or management thereof, e.g. service location protocol [SLP] or web services

Abstract

Systems, methods, and computer-readable media for improving the reliability of service function (SF) application in a service function chain (SFC) are provided. In some aspects, the subject technology facilitates automatic service function type validation by a service function forwarder (SFF), for example, by using a probe configured to query a function type of a SF module associated with the validating SFF.

Claims

1. A method for validating a service function type on a service function (SF) module, the method comprising:

initiating a probe, at a service function forwarder (SFF), to query a function type of a corresponding SF module;

receiving a reply from the corresponding SF module, in response to the probe, with an indication of an actual function being implemented by the corresponding SF module;

validating, at the SFF, the function type of the corresponding SF module by determining whether the actual function corresponds with an expected service function type using a forwarding database, the forwarding database maintaining the expected service function type, having a plurality of updatable function type values with each of the updatable function type values indicating a type, and including multiple entries for the SF module if the SF module has multiple ones of the expected service function type; and

determining, at the SFF, whether to permit packet forwarding, based on the function type of the corresponding SF module,

wherein,

if the function type is validated, the SFF permits a packet to be transmitted to a next hop, and

if the function type is not validated, the SFF drops the packet.

2. The method of claim 1, wherein initiating the probe further comprises:

detecting, at the SFF, a change in service function instantiation at the corresponding SF module; and

automatically initiating the probe in response to the change in service function instantiation.

3. The method of claim 1, wherein initiating the probe further comprises:

detecting, at the SFF, a change relative to the SFF; and

automatically initiating the probe in response to the change relative to the SFF.

4. The method of claim 1, wherein initiating the probe further comprises:

generating a request for the corresponding SF module;

setting a service path identifier (SPI) of the request to a service index limit (SIL) value; and

forwarding the request to a forwarding address associated with the corresponding SF module.

5. The method of claim 1, wherein receiving the reply from the corresponding SF module further comprises:

determining if the reply comprises correct SPI and SIL values; and

reading the function type from the reply.

6. The method of claim 1, wherein the forwarding database includes a service index path, a service index, and a next hop.

7. The method of claim 1, wherein the probe comprises a modified service function chain (SF) traceroute configured for a single-hop transmission to the corresponding SF module.

8. A service function type validation system comprising:

at least one processor; and

a memory device storing instructions that, when executed by the at least one processor, cause the validation system to;

initiate a probe, at a service function forwarder (SFF), wherein the probe is configured to query a function type of a corresponding SF module;

receive a reply from the corresponding SF module, in response to the probe, with an indication of an actual function being implemented by the corresponding SF module;

validate, at the SFF, the function type of the corresponding SF module by determining whether the actual function corresponds with an expected service function type using a forwarding database, the forwarding database maintaining the expected service function type, having a plurality of updatable function type values with each of the updatable function type values indicating a type, and including multiple entries for the SF module if the SF module has multiple ones of the expected service function type; and

determine, at the SFF, whether to permit packet forwarding, based on the function type of the corresponding SF module,

wherein,

the SFF is configured to permit a packet to be transmitted to a next hop if the function type is validated, and

the SFF is configured to drop the packet if the function type is not validated.

9. The service function type validation system of claim 8, wherein initiating the probe further comprises:

detecting, at the SFF, a change in service function instantiation at the corresponding SF module; and

automatically initiating the probe in response to the change in service function instantiation.

10. The service function type validation system of claim 8, wherein initiating the probe further comprises:

detecting, at the SFF, a change relative to the SFF; and

automatically initiating the probe in response to the change relative to the SFF.

11. The service function type validation system of claim 8, wherein initiating the probe comprises:

generating a service function chain request for the corresponding SF module;

setting a service path identifier (SPI) of the request to a service index limit (SIL) value; and

forwarding the request to an address associated with the corresponding SF module.

12. The service function type validation system of claim 8, wherein receiving the reply from the corresponding SF module further comprises:

determining if the reply comprises correct SPI and SIL values; and

reading the function type from the reply.

13. The service function type validation system of claim 8, wherein the forwarding database includes a service index path, a service index, and a next hop.

14. The service function type validation system of claim 8, wherein the probe comprises a modified service function chain (SF) traceroute configured for a single-hop transmission to the corresponding SF module.

15. A non-transitory computer-readable storage medium comprising instructions stored therein, which when executed by one or more processors, cause the processors to perform operations comprising:

initiating a probe, at a service function forwarder (SFF), wherein the probe is configured to query a function type of a corresponding SF module;

receiving a reply from the corresponding SF module, in response to the probe, with an indication of an actual function being implemented by the SF module;

validating, at the SFF, the function type of the corresponding SF module by determining whether the actual function corresponds with an expected service function type using a forwarding database, the forwarding database maintaining the expected service function type, having a plurality of updatable function type values with each of the updatable function type values indicating a type, and including multiple entries for the SF module if the SF module has multiple ones of the expected service function type; and

determining, at the SFF, whether to permit packet forwarding, based on the function type of the corresponding SF module,

wherein,

the SFF is configured to permit a packet to be transmitted to a next hop if the function type is validated, and

the SFF is configured to drop the packet if the function type is not validated.

16. The non-transitory computer-readable storage medium of claim 15, wherein initiating the probe further comprises:

detecting, at the SFF, a change in service function instantiation at the corresponding SF module; and

automatically initiating the probe in response to the change in service function instantiation.

17. The non-transitory computer-readable storage medium of claim 15, wherein initiating the probe further comprises:

detecting, at the SFF, a change relative to the SFF; and

automatically initiating the probe in response to the change relative to the SFF.

18. The non-transitory computer-readable storage medium of claim 15, wherein initiating the probe comprises:

generating a request for the corresponding SF module;

setting a service function index of the request to a service index limit (SIL) value; and

forwarding the request to an address associated with the corresponding SF module.

19. The non-transitory computer-readable storage medium of claim 15, wherein receiving the reply from the corresponding SF module further comprises:

determining if the reply comprises correct SPI and SIL values; and

reading the function type from the reply.

20. The non-transitory computer-readable storage medium of claim 15, wherein the forwarding database includes a service index path, a service index, and a next hop.