Configurable Service Proxy Mapping for Elastic Networks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current network service deployment models are static and inflexible, struggling to adapt to elastic service environments and virtualization, with limitations in service function ordering, policy application, and metadata management, leading to complex network changes and inefficiencies.

Innovation Solution

The implementation of a Network Service Header (NSH) with a variable set of context headers that enables flexible service chaining by carrying metadata for service function selection and policy enforcement, allowing for dynamic mapping of packets to service functions and supporting agile service delivery across virtual and physical networks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a static network service deployment model is used, then service functions are bound to fixed topology for insertion and policy selection, but the model does not adapt well to elastic service environments enabled by virtualization

Engineering Contradiction:
Improveadaptability to elastic service environmentsVSAvoidservice deployment model complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent implements dynamic service function chaining by replacing static topology-bound service insertion with dynamic service chains that can be programmatically configured and modified. Service functions are no longer fixed to specific network locations but can be dynamically selected and ordered based on virtualization layers and software-defined policies, enabling adaptation to elastic service environments while managing complexity through automation.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent introduces a new dimension of service deployment by adding virtualization layers above the physical network topology. Service functions can be instantiated and chained in the virtual domain independent of physical topology constraints, allowing services to be deployed, moved, and scaled without being bound to fixed physical locations, thus resolving the contradiction between adaptability and complexity.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Adaptability or versatility

If service functions are physically located at different points in the network infrastructure, then services can be deployed across WAN, data center, and campus networks, but the static deployment model limits flexible service insertion and policy application

Engineering Contradiction:
Improveflexible service insertion capabilityVSAvoidservice policy application ease
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent introduces service chains as an intermediary layer between physical network infrastructure and service functions. Service chains act as flexible mediators that can dynamically insert, remove, and reorder service functions across distributed network locations without requiring changes to the underlying physical topology or manual policy configuration, thus improving flexible service insertion while simplifying policy application through automated chain management.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates a universal service chain framework that can operate across diverse network infrastructures (WAN, data center, campus) with different service functions. The service chain mechanism provides multi-functional capability to insert various service types (firewall, load balancing, WAN acceleration) at any point in the network path, enabling flexible service insertion across distributed locations while maintaining consistent policy application methods.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If a static service deployment model is used, then topology binding provides fixed service insertion points, but the model cannot easily bind service policy to granular information such as per-subscriber state

Engineering Contradiction:
Improveservice policy granularityVSAvoidpolicy management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments service policies into granular, independently configurable elements within service chains. Each service function in the chain can be associated with specific policy rules that operate on granular information such as per-subscriber state, application type, or traffic flow characteristics. This segmentation allows fine-grained policy control without requiring complex monolithic policy management systems.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent enables dynamic parameter changes in service policy by allowing service chain configurations to be modified based on real-time conditions and granular information. Service policies can be adjusted at the individual service function level within the chain, enabling flexible binding to per-subscriber state and other granular parameters while managing complexity through parameterized policy templates and automated configuration management.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP3058687B1Configurable service proxy mapping
Publication Date: 2020.09.16 CISCO TECHNOLOGY INC
  • EP3058687B1 patent drawingFigure 1
  • EP3058687B1 patent drawingFigure 2A
  • EP3058687B1 patent drawingFigure 2B

AI summary

Presented herein are techniques in which a service proxy in a service node is configured to receive a packet encapsulated in a service header that includes a variable set of context headers. The service proxy is configured to use the context headers in the service header to map data in the packet to a local identifier that is associated with one of a plurality of service-functions hosted by the service node. The service proxy is further configured to forward the data in the packet to the service-function associated with the local identifier.