RSVP-based tunnel protocol providing integrated services
First Claim
1. A method for use in packet communication systems utilizing a Resource ReSerVation Protocol (RSVP), the method comprising the steps of:
- creating an RSVP PATH message at a packet sender, said RSVP PATH message containing information on routing reservation-request messages from a packet receiver to the packet sender;
sending said RSVP PATH message from the packet sender through a Tunnel Source Point (TSP) to the packet receiver through a Tunnel Destination Point (TDP), wherein a plurality of RSVP tunnels that can each transport one or more packet flows exist between the TSP and the TDP;
creating an RSVP RESV message at the packet receiver, said RSVP RESV message containing parameters for a proposed RSVP tunnel that would allow a set of aggregated individual packet flows to travel within a given Quality of Service (QoS) through said proposed RSVP tunnel;
sending said RSVP RESV message from the packet receiver to the TDP;
determining at the TDP an actual RSVP tunnel from the existing set of RSVP tunnels that is sufficient to satisfy the parameters contained within the RVSP RESV message;
assigning said set of aggregated individual packet flows to said determined RSVP tunnel;
creating a TUNNEL_BINDING object, said TUNNEL-BINDING object containing information on the assigned RSVP tunnel;
sending the RVSP RESV message and the TUNNEL_BINDING object from the TDP to the TSP;
sending the RVSP RESV message from the TSP to the packet sender; and
using the assigned RSVP tunnel for said set of aggregated individual packet flows sent through the TSP.
7 Assignments
0 Petitions
Accused Products
Abstract
A new RSVP-based tunnel protocol establishes packet tunnels between a tunnel source point (TSP) and a tunnel destination point (TDP) such that guaranteed services to aggregated packet flows is provided. In particular, an end-to-end RSVP session is mapped using a receiver-oriented RSVP type of signaling such that the TDP determines tunnel mapping. As such, this new RSVP-type of protocol is compatible with the receiver-driven nature of RSVP. Subsequent to admitting RSVP sessions, a tunnel tuning procedure dynamically adapts existing RSVP tunnels to traffic conditions in order to improve bandwidth efficiency. This tunnel tuning procedure may result in RSVP tunnel re-assignment of some of the admitted end-to-end sessions.
177 Citations
14 Claims
-
1. A method for use in packet communication systems utilizing a Resource ReSerVation Protocol (RSVP), the method comprising the steps of:
-
creating an RSVP PATH message at a packet sender, said RSVP PATH message containing information on routing reservation-request messages from a packet receiver to the packet sender;
sending said RSVP PATH message from the packet sender through a Tunnel Source Point (TSP) to the packet receiver through a Tunnel Destination Point (TDP), wherein a plurality of RSVP tunnels that can each transport one or more packet flows exist between the TSP and the TDP;
creating an RSVP RESV message at the packet receiver, said RSVP RESV message containing parameters for a proposed RSVP tunnel that would allow a set of aggregated individual packet flows to travel within a given Quality of Service (QoS) through said proposed RSVP tunnel;
sending said RSVP RESV message from the packet receiver to the TDP;
determining at the TDP an actual RSVP tunnel from the existing set of RSVP tunnels that is sufficient to satisfy the parameters contained within the RVSP RESV message;
assigning said set of aggregated individual packet flows to said determined RSVP tunnel;
creating a TUNNEL_BINDING object, said TUNNEL-BINDING object containing information on the assigned RSVP tunnel;
sending the RVSP RESV message and the TUNNEL_BINDING object from the TDP to the TSP;
sending the RVSP RESV message from the TSP to the packet sender; and
using the assigned RSVP tunnel for said set of aggregated individual packet flows sent through the TSP. - View Dependent Claims (2, 3, 4, 5, 6, 7)
further comprising the step of advertising said single delay value prior to sending the RSVP RESV message from the packet receiver to the TDP.
-
-
6. The method of claim 1 further comprising the step of tuning established tunnels by adjusting at least one tunnel parameter such as burst size.
-
7. The method of claim 1 further comprising the step of tuning established tunnels by re-configuring the established tunnels and, if necessary, re-assigning end-to-end RSVP sessions.
-
8. An improved apparatus acting as a Tunnel Destination Point (TDP) serving in a packet communication system utilizing a Resource ReSerVation Protocol (RSVP) and communicating with a Tunnel Source Point (TSP) through a plurality of RSVP tunnels that exist between the TSP and the TDP, wherein each tunnel can transport one or more packet flows, the improved apparatus comprising:
-
a packet server for receiving an RSVP RESV message from a packet receiver, said RSVP RESV message containing parameters for a proposed RSVP tunnel that would allow a set of aggregated individual packet flows to travel within a given Quality of Service (QoS) through said proposed RSVP tunnel;
said packet server determining an actual RSVP tunnel from the existing set of RSVP tunnels that is sufficient to satisfy the parameters contained within the RVSP RESV message;
said packet server assigning said set of aggregated individual packet flows to said determined RSVP tunnel;
said packet server creating a TUNNEL_BINDING object, said TUNNEL_BINDING object containing information on the assigned RSVP tunnel; and
said packet server sending the RVSP RESV message and the TUNNEL_BINDING object to the TSP. - View Dependent Claims (9, 10, 11, 12, 13, 14)
said packet server adverting said single delay value prior to receiving the RSVP RESV message from the packet receiver.
-
-
13. The improved apparatus of claim 8 wherein the packet server tunes established tunnels by adjusting at least one tunnel parameter such as burst size.
-
14. The improved apparatus of claim 8 wherein the packet server tunes established tunnels by re-configuring the established tunnels and, if necessary, re-assigning end-to-end RSVP sessions.
Specification