Method for link failure detection and session transfer to a lively link in the multihoming environment of ID/locator split-based networks
US-9628377-B2 · Apr 18, 2017 · US
US10887403B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-10887403-B2 |
| Application number | US-201715446184-A |
| Country | US |
| Kind code | B2 |
| Filing date | Mar 1, 2017 |
| Priority date | Jul 27, 2016 |
| Publication date | Jan 5, 2021 |
| Grant date | Jan 5, 2021 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
A computer-implemented method for data communication. In one example method, a first system sends an enhanced capability exchange (CAPEX) request message to a second system. The CAPEX request message includes a request to change the number of connection pipes on an established socket-based connection between the first system and the second system. The first system receives an enhanced CAPEX response message from the second system. The CAPEX response message accepts the request to change the number of connection pipes on the established connection. The first system changes the number of connection pipes on the established connection in accordance with the accepted request.
Opening claim text (preview).
What is claimed is: 1. A computer-implemented method comprising: sending, by a first system, a second capability exchange request message to a second system, wherein the second capability exchange request message requests a change to a number of connection pipes on an established socket-based connection between the first system and the second system, wherein a format of the second capability exchange request message includes an additional field, flag or other indicator as compared to a first capability exchange request message as sent by the first system, wherein the additional field, flag or other indicator of the second capability exchange request message indicates a request by the first system for enhanced socket handling; receiving, by the first system, a second capability exchange response message from the second system, wherein the second capability exchange response message accepts the request to change the number of connection pipes on the established connection, wherein a format of the second capability exchange response message includes an additional field, flag or other indicator as compared to a first capability exchange response message as sent from the second system, wherein the additional field, flag or other indicator of the second capability exchange CAPEX response message indicates an agreement by the second system to comply with an enhanced socket handling request; and changing, by the first system, the number of connection pipes on the established connection in accordance with the accepted request, wherein the changing of the number of connection pipes includes creating, by the first system, a new connection pipe of the established connection, wherein the new connection pipe transfers data in a queue; monitoring a volume of the data in the queue; comparing, by the first system, the monitored volume of the data in the queue with a minimum threshold data volume indicative of underutilization; and tearing down, by the first system, the new connection pipe in response to the monitored volume of data in the queue being less than the minimum threshold. 2. The method of claim 1 , further comprising: determining a demand for use of the established connection for a transfer of data from the first system to the second system; comparing the demand with a predetermined threshold; and identifying a requirement to change a capacity of the established connection, based on a determination that the demand exceeds the predetermined threshold. 3. The method of 1 , wherein comparing the demand with a predetermined threshold comprises: determining a demand for use of the established connection for a transfer of data from the first system to the second system; comparing the demand an upper predetermined threshold and a lower predetermined threshold; wherein: based on a determination that the demand is greater than the upper predetermined threshold, identifying a requirement to increase the number of connection pipes on the established connection; and based on a determination that the demand is less than the lower predetermined threshold, identifying a requirement to reduce the number of connection pipes on the established connection. 4. The method of claim 3 , comprising: sending the second capability exchange request message to the system in response to identifying the requirement to increase the number of connection pipes on the established connection; and sending a command message in response to identifying the requirement to reduce the number of connection pipes on the established connection. 5. A computer-implemented method, comprising: receiving, by a second system, a capability exchange request message from a first system; determining, by the second system, whether the capability exchange request message is a second capability exchange request message including a request to change a number of connection pipes on an established socket-based connection between the first system and the second system, wherein a format of the second capability exchange request message includes an additional field, flag or other indicator as compared to a first capability exchange request message as sent from the first system, wherein the additional field, flag or other indicator of the second capability exchange request message indicates a request by the first system for enhanced socket handling; based on a determination that the capability request message is a second capability exchange request message, initiating, by the second system, an enhanced capability exchange messaging sequence to change the number of connection pipes on the established connection; and sending, by the second system, a second capability exchange response message accepting the request to change the number of connection pipes on the established connection, wherein a format of the second capability exchange response message includes an additional field, flag or other indicator as compared to a first capability exchange response message as sent by the second system, wherein the additional field, flag or other indicator of the second capability exchange response message indicates an agreement by the second system to comply with an enhanced socket handling request, wherein the first system is configured to: change the number of connection pipes on the established connection in accordance with the accepted request, wherein the changing of the number of connection pipes includes creating, by the first system, a new connection pipe of the established connection, wherein the new connection pipe transfers data in a queue; monitor a volume of the data in the queue; compare the volume of the data in the queue with a minimum threshold data volume indicative of underutilization; and tear down the new connection pipe in response to the monitored volume of data in the queue being less than the minimum threshold. 6. The method of claim 5 , wherein determining whether the capability exchange request message is a second capability exchange request message comprises identifying the additional flag, field or indicator of the second capability request message. 7. The method of claim 5 , further comprising: receiving a command message, the command message including a command to reduce the number of connection pipes on the established connection, and closing a socket associated with a connection pipe in response to receiving the command message.
Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities (flow or congestion control using dynamic resource allocation, e.g. in-call renegotiation, H04L47/76) · CPC title
taking into account QoS or priority requirements · CPC title
Delays · CPC title
Migration or transfer of sessions · CPC title
characterised by the conditions triggering a change of settings · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.