Multiplex communications – Data flow congestion prevention or control – Control of data admission to the network
Reexamination Certificate
1998-10-22
2003-11-04
Kizou, Hassan (Department: 2662)
Multiplex communications
Data flow congestion prevention or control
Control of data admission to the network
C370S231000, C370S235000, C370S253000
Reexamination Certificate
active
06643258
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a communication resource management method and a node device for the purpose of providing a certain level of communication quality in a packet communication network.
2. Description of the Background Art
In the IP (Internet Protocol) network, for instance, an amount of delay caused for packets will be larger when the number of packets that arrive at a router for carrying out packet transfer becomes larger. In this case, however, each terminal is responsible for making a Judgement as to whether or not to reduce a load of the router by limiting the number of packets to be transmitted from the terminal, and the terminal has no obligation to limit the number of packets to be transmitted.
This is due to the fact that the Internet Protocol is designed without any consideration for guaranteeing the communication quality. For this reason, the IP network basically cannot guarantee the communication quality with respect to a user. However, in order to realize the video image communication, for example, there is a need to guarantee the communication quality such as packet transfer delay, so that there have been many propositions for a scheme that guarantees the communication quality in the IP network.
For instance, in the standardization organization called IETF, the service specification called “Guaranteed Service” (S. Shenker et al., “Specification of Guaranteed Quality of Service”, Internet Draft draft-ietf-intserv-guaranteed-svc-08.txt) and the service specification called “Controlled Load Service” (J. Wroclawski, “Specification of the Controlled-Load Network Element Service”, Internet Draft draft-ietf-intserv-ctrl-load-svc-05.txt) have been proposed in the IntServ working group.
In these schemes, a bandwidth reservation request is notified to each node on the route of a flow, and a node that received the bandwidth reservation request accepts that bandwidth reservation request if there are enough communication resources for guaranteeing the communication quality within that node itself. Then, when packets belonging to a flow that requests the bandwidth arrive, each node on the route carries out the packet policing or packet scheduling according to values of traffic parameters reported for that flow so as to guarantee the communication quality. Here, the flow is defined as a group of packets which share the same destination address, destination port number, source address, source port number and protocol number, according to RSVP (R. Braden et al., “Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification, Internet Draft draft-ietf-rsvp-spec-16.txt), for example.
As an example of the scheduling algorithm, SCFQ (S. Jamaloddin Golestani, “A Self-Clocked Fair Queueing Scheme for Broadband Applications”, Proc. of Infocom 94, pp. 636-646, 1994) can be mentioned. In the SCFQ, the evaluation value based on the bandwidth allocated to the flow is calculated for each flow and packets of the flow that has the minimum value for this evaluation value will be transmitted. As such, the SCFQ requires the processing for each flow, so that there is a problem that its realization is difficult when a large number of flows are involved. This problem of a large processing load in the case of a large number of flows is also similarly present in the other scheduling algorithms.
Also, the policing function which monitors an amount of arriving packets requires the processing for each flow so that there is a problem of a large processing load in the case of a large number of flows.
Also, when the bandwidth request is made using the RSVP, for example, control packets of the RSVP will be periodically transmitted and received for each flow, so that there is also a problem that a load for processing these control packets becomes large in the case of a large number of flows.
As described, in the scheme in which each node in the network makes a judgement as to whether or not to accept the bandwidth reservation request and carries out the scheduling or policing for each flow from which the bandwidth reservation request has been accepted, there is an advantage in that it is possible to guarantee the communication quality with respect to a flow from which the bandwidth reservation request has been accepted, but there is also a drawback in that the processing load of each node becomes large.
On the other hand, there is also a proposition of a scheme in which an edge node provided at an ingress side of the network writes a tag indicating the priority class in a packet based on the bandwidth allocated to the flow of that packet, and each node inside the network carries out the priority control or scheduling according to the tag written in the packet, instead of carrying out the policing or scheduling that requires the processing for each flow at each node of the network as described above.
Each node inside the network does not have the problem of large processing power required to handle a large number of flows because packet priority control or packet scheduling is done not for each flow but for each priority class.
For instance, in the IETF, the scheme called “Differential Service (D. Clark and J. Wroclawski, “An Approach to Service Allocation in the Internet”, Internet Draft draft-clark-diff-svc-alloc-00.txt) and the scheme called “SIMA” (K. Kilkki “Simple Integrated Media Access (SIMA)”, Internet Draft draft-kalevi-simple-media-access-01.txt) have been proposed. These are schemes in which a tag indicating a high priority level is written into a packet at a rate proportional to the bandwidth allocated to the flow.
For example, in the case of allocating a bandwidth of 100 [Kbps] to a flow A, the edge node provided at the ingress side of the network monitors the flow A, and writes a value indicating a high priority level in packets up to 100 [Kbps]. At a node inside the network, when congestion occurs, packets with a lower priority level is much more likely to be discarded than packet with higher priority level. In this way, the packets belonging to the flow A will be transferred at a high priority level within the range of 100 [Kbps].
Thus the flow can receive the transfer service at the high priority level as much as the bandwidth that are allocated to it. In this scheme, it suffices for the node inside the network to deal with the priority level written in the packets without becoming conscious of the flow so that there is an advantage that it is sufficient to carry out a simple processing.
FIG. 1
shows an exemplary realization of the differential service. In
FIG. 1
, a flow A and a flow B are transferred through a network
301
. This network
301
comprises core nodes
101
-
103
and edge nodes
201
-
204
, which are connected through communication links. The core nodes
101
-
103
carry out the priority processing at a time of packet transfer according to priority tags written in packets. The edge nodes
201
-
204
are located outside the core nodes
101
-
103
and write tags indicating the priority levels with respect to packets of the respective flows.
Within the network
301
, the flow A is transferred through a route of the edge node
204
, the core node
103
, the core node
102
, and the edge node
202
, while the flow B is transferred through a route of the edge node
201
, the core node
101
, the core node
102
, and the edge node
202
. The edge node
204
writes a tag indicating the high priority level into packets up to 100 [Kbps] among the packets belonging to the flow A, while the edge node
201
writes a tag indicating the high priority level into packets up to 200 [kbps] among the packets belonging to the flow B. At the nodes
101
-
103
and
201
-
203
inside the network
301
, when it is inevitable to discard some packets, the low priority packets, i.e., those packets in which the high priority tag is not written, will be discarded at a high priority. As a result, in this network
301
, the packets belonging to the flow A up to 100 [Kbps]
Ise Kotaro
Katsube Yasuhiro
Shimojo Yoshimitsu
Foley & Lardner
Kabushiki Kaisha Toshiba
Kizou Hassan
Tsegaye Saba
LandOfFree
Communication resource management method and node device... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Communication resource management method and node device..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Communication resource management method and node device... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3171502