Providing admission control and network quality of service...

Details Providing admission control and network quality of service... Providing admission control and network quality of service...

1998-11-18

2002-11-26

Yao, Kwang Bin (Department: 2662)

Multiplex communications

Data flow congestion prevention or control

Control of data admission to the network

C370S395200, C370S468000

Reexamination Certificate

active

06487170

ABSTRACT:

COPYRIGHT NOTICE
Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise deserves all rights to the copyright whatsoever.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates generally to the field of computer networking devices. More particularly, the invention relates to a method and apparatus for providing admission control and network Quality of Service (QoS).
2. Description of the Related Art
The Internet and Enterprise networks, such as Intranets and Extranets, are expected to support diverse types of traffic including voice, file transfer data, interactive multimedia, real-time video, and rich graphic images. Additionally, despite exponential growth in the number of Internet users and the corresponding increase in demand for network bandwidth, expectations about the quality and timely presentation of information received from networks are higher than ever.
It has long been recognized that increased network speed and bandwidth alone will not satisfy the high demands of today's networks. Rather, distinguished qualities of service for various applications need to be provided. The Integrated Services (IntServ) architecture and Resource Reservation Protocol (RSVP) were developed to foster growth of Quality of Service (QoS) enabled networks. RSVP is an Internet Protocol- (IP) based protocol that allows applications running on end-stations, such as desktop computers, to communicate per-flow requirements by signaling the network.
Referring now to
FIG. 1
, an RSVP resource reservation setup for a data flow is briefly described. For further information on IntServ and RSVP see Braden, R., Clark, D. and Shenker, S., “Integrated Services in the Internet Architecture: an Overview”, Internet RFC 1633, June 1994 and Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S., “Resource Reservation Protocol (RSVP) Version 1 Functional Specification”, RFC 2205, Proposed Standard, September 1997, respectively. In this example, an IntServ network cloud
100
includes core devices
121
-
125
, an ingress edge device
150
, and an egress edge device
160
. The source of a data stream, such as sender
130
, transmits a Path message downstream toward potential recipients of the data stream. The Path message causes path state information, such as information regarding the reverse path to the sender
130
, to be stored in each node along the way. Subsequently, end-stations that are interested in receiving the data stream may request a specific QoS for the data stream. In this example, receiver
140
initiates resource reservation setup by communicating its requirements to an adjacent router, e.g., edge device
160
. The receiver's requirements are communicated by transmitting a reservation request (Resv) message upstream toward sender
130
. The receiver's requirements, e.g., desired QoS and a description of the data flow, are passed back to all intervening routers, e.g., core devices
121
,
123
, and
124
, between the receiver
140
and the sender
130
and finally to the sender
130
itself. The Resv message causes each of the core devices
121
,
123
, and
124
along the path the data packets to create and maintain reservation state information. In this example, the reservation state information and the path state information are together referred to as flow state information
180
. Flow state information
180
is stored in each core device on the path between the sender
130
and the receiver
140
. RSVP's reliance on per-flow state information and per-flow processing raises scalability concerns in large networks. As a result, only a small number of hosts actually generate RSVP signaling.
The scalability concerns raised by the combination of RSVP and IntServ led to the development of the Differentiated Services (DiffServ) Architecture. DiffServ allows distinct levels of network service to be provided to different traffic. However, rather than storing per-flow state information on each intermediate node in the network between the sender and the receiver(s), routers within a DiffServ network handle packets on different traffic flows by applying different per-hop behaviors (PHBs) based upon the setting of bits in the TOS field of each packet's IP header. In this manner, many traffic flows may be aggregated into one of a small number of predefined PHBs, thereby allowing a reduction in the amount of processing and storage associated with packet classification and forwarding. While solving the scalability issues raised by the RSVP/IntServ combination, DiffServ fails to provide adequate guidance with regard to implementation of an admission control policy.
An allocation method suggested by the DiffServ framework will now briefly be described with reference to
FIGS. 2A and 2B
. One approach for performing admission control suggested by the DiffServ framework involves using a centralized bandwidth broker
210
. The centralized bandwidth broker
210
has control over the entire domain and centrally handles bandwidth allocation requests. In this example, a DiffServ network cloud
200
includes core devices
221
-
225
, an ingress edge device
250
, and an egress edge device
260
. A sender
230
wishing to establish a particular level of service for a data flow between it and a receiver
240
transmits an indication of its requirements to the ingress edge device
250
. The ingress edge device
250
communicates the requirements to the centralized bandwidth broker
210
. The centralized bandwidth broker
210
validates the request against policies, compares the request against the current allocation of bandwidth for accepted traffic, and configures the edge devices
250
and
260
with information needed to mark and shape (or police) incoming packets for the flow. Subsequently, as packets that are part of the established data flow traverse the DiffServ network cloud
200
, the intermediate core devices
221
-
225
apply a PHB that corresponds to the DiffServ service level indicated in the packet header.
While conceptually simple, the implementation of a useful centralized bandwidth broker may be very complex. In addition, the practicality of a centralized bandwidth broker is questionable at best. For example, a centralized bandwidth broker has limited capability to handle bandwidth requests for multicast sessions. Also, one obstacle in implementing a centralized bandwidth broker is supplying complete information to the centralized bandwidth broker regarding the network topology and information regarding current allocation of bandwidth for individual paths traversing the network. In order to avoid the complexity of such a full-topology scheme, the centralized bandwidth broker
210
may conceptually view the DiffServ network cloud
200
as having a logical bottleneck equal to the weakest link
270
in the domain for any ingress/egress edge device pair. For example, because the centralized bandwidth broker
210
may not have knowledge of the network topology, it may simply condense the network topology of its entire domain of authority into a single imaginary logical link
280
that has a capacity equivalent to the weakest link
270
in the domain. A network manager may manually configure the centralized bandwidth broker
210
with this information, for example. As a result of this simplification, the network topology of
FIG. 2A
will be condensed to the single imaginary logical link
280
shown in FIG.
2
B. While this simplification reduces the centralized bandwidth broker's admission control decision to a comparison of the new request against the current allocation of bandwidth for the imaginary logical link
280
, one limitation of this scheme is that it can result in a network that is over provisioned or under utilized.
In light of the foregoing, what is needed is a more intelligent mechanism for implementing admission control policy in a

Affiliated with

Also associated with

Rating

Providing admission control and network quality of service... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Providing admission control and network quality of service..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Providing admission control and network quality of service... will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2969370