RSVP-based tunnel protocol providing integrated services

Details RSVP-based tunnel protocol providing integrated services RSVP-based tunnel protocol providing integrated services

1999-02-26

2003-02-11

Olms, Douglas (Department: 2732)

Multiplex communications

Pathfinding or routing

Switching a message which includes an address header

C370S235000, C370S395210, C370S395400, C370S465000, C709S221000, C709S227000

Reexamination Certificate

active

06519254

ABSTRACT:

FIELD OF THE INVENTION
This invention relates generally to communications and, more particularly, to packet communications systems.
BACKGROUND OF THE INVENTION
In the past, all data traffic using the Internet was treated equally and transported using a “best effort” mechanism. However, over time, the need to support real-time applications over the Internet (e.g., audio/video conferencing tools, gaming applications, etc.) necessitated some form of differentiated services offering. As such, those in the art are defining new protocols for providing quality of service (QoS) to Internet users.
The Resource ReSerVation Protocol (RSVP) is one such protocol. RSVP is a receiver-driven, end-to-end, protocol used by receiving hosts to signal the desired quality-of-service (QoS) to the network elements along a data flow path. In RSVP, the granularity of a QoS request is determined on a per packet flow basis (e.g., see R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “
Resource ReSerVation Protocol
(
RSVP
)-
Version
1
Functional Specification
,” RFC 2205).
However, providing a QoS guarantee on a per-packet flow basis creates scalability problems on backbone routers (e.g., see “
Aggregating RSVP
-
based QoS Requests
,” by R. Guerin, S. Blake, S. Herzog., draft-guerin-aggreg-rsvp-00.txt, November 1997). For example, for each packet flow (also referred to herein as a Transaction-Control-Protocol/Internet-Protocol (TCP/IP) session) in a router, there is a reservation state comprising, e.g., TCP/IP source, TCP/IP destination, and TCP/IP protocol number. As such, the necessity for a router to track each individual TCP/IP sessions takes up significant router memory and processing resources. In addition, the end-to-end nature of RSVP makes it unsuitable to be used for reserving virtual pipes through the network.
One solution to the above problem is to aggregate the packet flows and provide RSVP tunnels between two routers as described in “
Aggregating RSVP
-
based QoS Requests
,” by—R. Guerin, S. Blake, S. Herzog., draft-guerin-aggreg-rsvp-00.txt, November 1997; and “
RSVP Operations over IP tunnels
,” by A. Terzis, J. Krawczyk, J. Wroclaski, L. Zhang, draft-ietf-rsvp-tunnel-03.txt, August 1998. Now, the RSVP sessions passing through a pair of tunnel end points may provide different services (e.g., guaranteed service (guarantees a worst-case delay) or controlled load service (guarantees a mimimum bandwidth)), the same service with different parameters (e.g., different delay requirement in guaranteed service), or similar services with different policies. Thus there may exist a number of different tunnels between a pair of tunnel end points.
SUMMARY OF THE INVENTION
Although the above-mentioned modified form of RSVP, which aggregates RSVP-based QoS requests, is a solution to the problem, such a modified form of RSVP is no longer purely receiver-oriented. In particular, the information carried in the end-to-end RSVP RESV message (from the receiver to the sender) is not used by the tunnel source point in making the decision on session-to-tunnel mapping. This not only violates the receiver-oriented paradigm of RSVP, but also may result in inefficiency of bandwidth utilization.
Therefore, we have developed a new RSVP-based tunnel protocol that establishes an end-to-end RSVP session over a packet tunnel between a tunnel source point (TSP) and a tunnel destination point (TDP) in a fashion that is consistent with the RSVP receiver-driven paradigm. 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 consistent with the receiver-driven nature of RSVP and therefore requires no changes to the existing RSVP protocol.
In an embodiment of the invention, the RSVP protocol is modified to support receiver-oriented mapping of end-to-end RSVP sessions to tunnels between a TSP and a TDP. In particular, the TDP uses information carried in the end-to-end RSVP RESV message to determine the session-to-tunnel mapping. This mapping is transmitted to the TSP via a new TUNNEL_BINDING object.
In accordance with other features of the invention, when providing guaranteed service, the TDP dynamically configures tunnels to the TSP, and performs tunnel tuning for established tunnels. The latter feature permits dynamically adapting existing tunnels to traffic conditions in order to improve bandwidth efficiency. The tunnel tuning procedure may result in tunnel re-assignment of some of the admitted end-to-end RSVP sessions.


REFERENCES:
patent: 4119796 (1978-10-01), Jones
patent: 4604582 (1986-08-01), Strenkowski et al.
patent: 5081655 (1992-01-01), Long
patent: 5410570 (1995-04-01), Ladha et al.
patent: 5509037 (1996-04-01), Buckner et al.
patent: 5509038 (1996-04-01), Wicki
patent: 5553104 (1996-09-01), Takashi et al.
patent: 5577075 (1996-11-01), Cotton et al.
patent: 5592519 (1997-01-01), Honaker, Jr.
patent: 5638410 (1997-06-01), Kuddes
patent: 5673415 (1997-09-01), Nguyen et al.
patent: 5687202 (1997-11-01), Eitrheim
patent: 5712882 (1998-01-01), Miller
patent: 5903559 (1999-05-01), Acharya et al.
patent: 6286052 (2001-09-01), McCloghrie et al.
patent: 6182149 (2002-01-01), Nessett et al.
patent: 02000253071 (2000-09-01), None
R. Guerin, S. Blake, and S. Herzog, “Aggregating RSVP-based QoS Requests”, draft-guering-aggreg-rsvp-00, txt, Nov. 1997.
S. Rampal and R. Guerin, “Flow Grouping For Reducing Reservation Requirements for Guaranteed Delay Service”, draft-rampal-flow-delay-service-01.txt, Jul. 1997.
R. Baden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource ReSerVation Protocol(RSVP)—Version 1 Functional Specification”, Nework Working Group RFC 2205, Sep. 1997.
S. Shenker, C. Partridge, and R. Guerin, “Specification of Guaranteed Quality of Service”, Network Working Group, RFC 2212, Sep. 1997.
S. Shenker and J. Wroclawski, “General Characterization Parameters for Integral Service Network Elements”, Network Working Group RFC 2215, Sep. 1997.
A. Terzis, J. Krawczyk, J. Wroclaski, and L. Zhang, “RSVP Operations over IP tunnels”, draft-ietf-rsvp-tunnel-03.txt, Aug. 1998.
J. Wroclawski, “The Use of RSVP with IETF Integrated Services”, Network Working Group, RFC 2210, Sep. 1997.
“QoS-adaptation by software agents in the presence of defective reservation mechanisms in the Internet” (1998 IEEE, Jun. 30-Jul. 2, 1998, by De Meer, H., et al.).
“Bandwidth-guaranteed IP tunneling router with RSVP” (1998 IEEE, Feb. 16-18, 1998, by Ito, Y., et al.).

Affiliated with

Also associated with

Rating

RSVP-based tunnel protocol providing integrated services does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with RSVP-based tunnel protocol providing integrated services, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and RSVP-based tunnel protocol providing integrated services will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3171815