Service Function Chain Forwarding Without Metadata Handling

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current network deployments require service functions to handle additional packet level encapsulations for service function chain information, which can be challenging due to the lack of capability in existing systems to manage these encapsulations effectively.

Innovation Solution

A method that maps a tunnel identifier of an encapsulated data packet to an attachment circuit of a service function and rewrites the destination media access control (MAC) address of the data packet to the MAC address of the service function, allowing service functions to remain oblivious to underlying chain implementations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If service functions are decoupled from network topology and deployed as virtualized functions in a service function chain, then flexibility and adaptability are improved, but device complexity increases due to the need for packet level encapsulations and metadata handling

Engineering Contradiction:
ImproveflexibilityVSAvoidcomplexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent extracts the service function chain metadata and encapsulation handling from the service functions themselves and places it in the service function forwarders. This allows service functions to remain simple and oblivious to the chaining mechanism while still enabling flexible virtualized deployment. The metadata is separated into a distinct layer handled by forwarders rather than being embedded in service function logic.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The service function forwarder acts as an intermediary between the service function chain metadata and the actual service functions. It receives packets with chain information, processes the metadata, and forwards packets to appropriate service functions. This intermediary layer absorbs the complexity of encapsulation and metadata management, shielding service functions from these complications.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If service functions handle additional service function chain encapsulations, then service function chain capability is improved, but ease of operation deteriorates due to the need for service functions to process additional metadata

Engineering Contradiction:
Improveservice function chain capabilityVSAvoidease of operation
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent extracts the metadata processing responsibility from service functions and relocates it to service function forwarders. Service functions only handle actual service processing logic, not chain metadata. This separation maintains full service function chain capability while making service functions easier to operate and manage, as they don't need to understand or process encapsulation metadata.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The service function forwarder serves as an intermediary that handles all metadata processing and encapsulation tasks. Service functions simply interact with the forwarder, which manages the complexity of chain information. This makes service functions easier to operate since they don't need to handle additional metadata, while the forwarder ensures service function chain capability is maintained.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Device complexity

If service functions are tightly coupled to underlying network topology, then device complexity is reduced, but adaptability deteriorates due to rigid and static deployments

Engineering Contradiction:
ImprovesimplicityVSAvoidadaptability
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The patent segments the service function deployment from the network topology by introducing virtualized service functions that can be instantiated independently of physical network connections. Service functions are deployed as virtual entities that can be dynamically allocated to different physical locations. This segmentation enables adaptability while keeping individual service function components relatively simple.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces dynamic deployment capabilities where service functions can be dynamically instantiated, moved, and allocated based on network conditions and requirements. The service function chain can be dynamically configured and reconfigured without changing underlying network topology. This dynamic approach provides adaptability while maintaining operational simplicity through automated provisioning and management.

Inventive Principle:
Principle #15Dynamics

Data Source

PatentUS12418440B2Method to build a service function chain in an overlay network
Publication Date: 2025.09.16 GOOGLE LLC
  • US12418440B2 patent drawing
  • US12418440B2 patent drawing
  • US12418440B2 patent drawing

AI summary

Implementations are provided for building a service function chain in a network that can remove the requirement to encapsulate packet level metadata or other packet levels in a service function chain. The approach allows for implementing service function chains while separating chain metadata from the service function so that service functions are not required to support handling service function chaining metadata. The approach can map a tunnel identifier of an encapsulated data packet to an attachment circuit of a service function and can rewrite the destination media access control (MAC) address of the data packet to the MAC address of the service function.