RSVP-based tunnel protocol providing integrated services

• US 6,519,254 B1
• Filed: 02/26/1999
• Issued: 02/11/2003
• Est. Priority Date: 02/26/1999
• Status: Expired due to Term

• Current Assignee: WSOU Investments, LLC (WSOU Holdings, LLC)
• Original Assignee: Lucent Technologies, Inc. (Nokia Corporation)
• Inventors: Yan, Anlu, Kodialam, Muralidharan Sampath, Chuah, Mooi Choo
• Primary Examiner(s): Olms, Douglas
• Assistant Examiner(s): HOM, SHICK C
• Application Number:
  US09/259,170
• Time in Patent Office: 1,446 Days
• Field of Search: 370/235, 370/254, 370/389, 370/395.2, 370/395.21, 370/395.3, 370/395.31, 370/395.4, 370/395.41, 370/395.42, 370/395.43, 370/395.5, 370/395.51, 370/395.52, 370/465, 709/200, 709/203, 709/220, 709/221, 709/222, 709/227, 709/228
• US Class Current: 370/389
• CPC Class Codes: H04L 12/4633 Interconnection of networks using encapsulation techniques, e.g. tunneling
• CPC Class Codes: H04L 47/70 Admission control; Resource allocation
• CPC Class Codes: H04L 47/724 at intermediate nodes, e.g. resource reservation protocol [RSVP]
• CPC Class Codes: H04L 47/825 Involving tunnels, e.g. MPLS

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.

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.

2. The method of claim 1 further comprising the step of encapsulating the RVSP RESV message.

3. The method of claim 2 wherein the TUNNEL_BINDING object is attached to the encapsulated RSVP RESV message.

4. The method of claim 1 wherein the step of determining an actual RSVP tunnel is a function of a slack time value extracted from the received RSVP-based signaling and a minimum tunnel delay value.

5. The method of claim 1 wherein attached to the RSVP PATH is an AdSpec object, said AdSpec object containing a single delay value;

and

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.

9. The improved apparatus of claim 8 wherein the packet server sends an encapsulated form of the RVSP RESV message.

10. The improved apparatus of claim 9 wherein the TUNNEL_BINDING object is attached to the encapsulated RSVP RESV message.

11. The improved apparatus of claim 8 wherein the packet server determines an actual RSVP tunnel as a function of a slack time value extracted from the received RSVP-based signaling and a minimum tunnel delay value.

12. The improved apparatus of claim 8 wherein the packet server attaches to the RSVP PATH an AdSpec object, said AdSpec object containing a single delay value;

and

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.