RSVP Message Bandwidth Reservation via Multiple TSPEC Objects

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The existing Resource Reservation Protocol (RSVP) is inefficient in reserving bandwidth for flows due to the need for multiple reservation requests, which can be time-consuming and may not always result in the desired bandwidth allocation.

Innovation Solution

Incorporating multiple bandwidth requests within a single RSVP message using multiple traffic specification (TSPEC) objects, allowing nodes to maintain multiple potential reservation states and switch to a lower bandwidth if the higher requested bandwidth is not accommodated.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If multiple separate RESV messages are sent to reserve bandwidth, then the desired bandwidth may be reserved, but the process becomes time-consuming and inefficient

Engineering Contradiction:
Improvebandwidth reservation successVSAvoidreservation setup time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent combines multiple bandwidth reservation requests into a single RESV message by including multiple TSPEC objects within one message. This merging approach allows the endpoint to request multiple bandwidth allocations simultaneously rather than sending separate RESV messages for each bandwidth request, thereby reducing the time required for bandwidth reservation while maintaining the reliability of securing the desired bandwidth.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent enables preliminary action by including multiple TSPEC objects in advance within a single RESV message. The endpoint prepares multiple bandwidth requests beforehand and presents them all at once to the network nodes, allowing the reservation process to complete in a single pass rather than requiring multiple sequential attempts, thus reducing setup time.

Inventive Principle:
Principle #10Preliminary action

2Device complexity

If a single RESV message requests a specific bandwidth, then the request is simple, but it may not be accommodated and requires sending additional messages

Engineering Contradiction:
Improvereservation message structureVSAvoidbandwidth reservation efficiency
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The patent merges multiple bandwidth requests into a single RESV message structure by incorporating multiple TSPEC objects. This approach increases the information content and functionality of the reservation message without requiring multiple separate message exchanges, thereby improving reservation efficiency while maintaining manageable message complexity through standardized object formatting.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The patent enhances the universality of the RESV message by enabling it to carry multiple TSPEC objects that represent different bandwidth requests. This multi-functional capability allows a single message to serve multiple reservation purposes simultaneously, improving productivity by eliminating the need for sequential message exchanges while the standardized TSPEC object format keeps the message structure organized and manageable.

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

Data Source

PatentEP2356780B1Executing and supporting a multiple bandwidth reservation request
Publication Date: 2016.04.06 CISCO TECHNOLOGY INC
  • EP2356780B1 patent drawingFigure 1A~1B
  • EP2356780B1 patent drawingFigure 1C
  • EP2356780B1 patent drawingFigure 2

AI summary

In one embodiment, a method includes obtaining a first message that includes at least a first bandwidth request that specifies a first bandwidth and a second bandwidth request that specifies a second bandwidth. The first bandwidth is a preferential bandwidth. The method also includes determining whether the first bandwidth may be allocated, and storing the first bandwidth and the second bandwidth in a stored reservation state if the first bandwidth may be allocated. If the first bandwidth may not be allocated, the method includes determining whether the second bandwidth may be allocated. The second bandwidth in the stored reservation state if it is determined that the second bandwidth may be allocated. In one embodiment, if the second bandwidth may be allocated, the first bandwidth is removed during process prior to sending the message to a subsequent node upstream.