Service Function Chain Metadata Application Identifier

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Service Function Chaining (SFC) technologies face challenges in ensuring interoperability and understanding policies across different devices and vendors, as carrying policies in metadata is not sufficient for all nodes in the SFC to recognize and process, leading to inconsistencies in application identification and statistics collection.

Innovation Solution

Augmenting packet metadata with application identifiers before ingress into a Service Function Path (SFP), using a standardized format like IPFIX, to provide normalized application identification across multiple devices and vendors, enabling structured analysis and statistics collection through analytics engines.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If policies are carried in metadata for Service Function Chaining, then classification results can be applied across SF nodes, but interoperability and policy understanding across different devices and vendors cannot be guaranteed

Engineering Contradiction:

Improvepolicy application efficiencyVSAvoidinteroperability consistency

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The patent applies universality by using standardized protocol fields (IPFIX applicationIdentifier, NSH application identifier) that can be universally recognized across different vendors and devices. This standardization enables the same metadata structure to serve multiple purposes: carrying classification results, enabling policy propagation, and ensuring interoperability across heterogeneous SFC nodes simultaneously.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent changes the parameter representation by encoding application identification information in standardized protocol parameters (IPFIX applicationIdentifier field, NSH application identifier field) rather than vendor-specific formats. This parameter standardization transforms the metadata into a universally interpretable form that maintains both efficiency and reliability across different implementations.

Inventive Principle:

Principle #35Parameter changes

2Adaptability or versatility

If vendor-specific metadata formats are used, then device implementation flexibility is maintained, but consistent application identification across multi-vendor environments is lost

Engineering Contradiction:

Improvedevice implementation flexibilityVSAvoidapplication identification consistency

Core Design Contradiction:

Adaptability or versatilityVSMeasurement precision

Solution Approach 1:

The patent achieves universality by designing metadata structures that conform to standardized protocols (IPFIX, NSH) which can be implemented across different vendors while maintaining consistent application identification. The standardized fields serve as universal containers that preserve both implementation flexibility and identification consistency simultaneously.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent introduces standardized protocol fields as intermediaries between vendor-specific implementations and the requirement for consistent application identification. These standard fields act as mediators that translate diverse vendor implementations into a common language, enabling precise application identification across multi-vendor SFC environments.

Inventive Principle:

Principle #24Intermediary (Mediator)

3Ease of manufacture

If application identifiers are not standardized, then each device can use its own format, but statistics collection and data correlation across SFC nodes become inaccurate

Engineering Contradiction:

Improvedevice implementation easeVSAvoidstatistics collection accuracy

Core Design Contradiction:

Ease of manufactureVSMeasurement precision

Solution Approach 1:

The patent changes the parameter format to standardized protocols (IPFIX applicationIdentifier, NSH application identifier) that enable accurate statistics collection and data correlation across SFC nodes. This parameter standardization maintains ease of implementation through widely-supported protocols while ensuring measurement precision in application identification and flow correlation.

Inventive Principle:

Principle #35Parameter changes

Data Source

PatentUS10887220B2Application identifier in service function chain metadata

Publication Date: 2021.01.05 CISCO TECHNOLOGY INC

AI summary

This disclosure pertains to augmenting metadata of a packet destined for service function chaining with application identifier information. The application identifier information can be added to the metadata of a packet service header (or, more specifically, a network service header). The packet can be exported to a statistics collector that can correlate statistical information about the application with statistical information about service functions applied to the packet, as well as other statistical information.