This invention relates generally to communications and, more particularly, to packet communications systems.
In the past, all data traffic using the Internet was treated equally and transported using a xe2x80x9cbest effortxe2x80x9d 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, xe2x80x9cResource ReSerVation Protocol (RSVP)-Version 1 Functional Specification,xe2x80x9d RFC 2205).
However, providing a QoS guarantee on a per-packet flow basis creates scalability problems on backbone routers (e.g., see xe2x80x9cAggregating RSVP-based QoS Requests,xe2x80x9d 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 xe2x80x9cAggregating RSVP-based QoS Requests,xe2x80x9d byxe2x80x94R. Guerin, S. Blake, S. Herzog., draft-guerin-aggreg-rsvp-00.txt, November 1997; and xe2x80x9cRSVP Operations over IP tunnels,xe2x80x9d 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.
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.
USPTO Backgrounds
USPTO Backgrounds