Multiplex communications – Data flow congestion prevention or control – Flow control of data transmission through a network
Reexamination Certificate
1999-11-30
2004-01-06
Pham, Chi (Department: 2663)
Multiplex communications
Data flow congestion prevention or control
Flow control of data transmission through a network
Reexamination Certificate
active
06674722
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to a method for controlling the flow of data messages exchanged between asynchronous digital stack processes in an unreliable distributed multiprocessor system. In addition, the invention relates to the use of the method in an SDH node.
2. Description of the Related Art
To better understand the background of the invention let us consider the block diagram in
FIG. 1
showing part of an SDH (Synchronous Digital Hierarchy) node. Shown here by way of example is a node of the Synfonet system from Nokia Telecommunications. The Synfonet node is a configurable network element which for synchronous transport module STM-1/STM-4 connections can be configured into a terminal multiplexer (TM), add & drop multiplexer (ADM), digital cross-connect (DXC) and regenerator (REG). The node is a small unit to which various types of electrical and optical interface units and switch elements can be connected as plug-in units. The configuration can be changed from a simple SDH application to part of large SDH networks by adding and removing plug-in units. The processing capacity of the node is distributed so that all plug-in units have microprocessors of their own and the software as well as the configuration data can be distributed between multiple units, which adds to the reliability and processing capacity of the system. For network management (Telecommunication Management Network, TMN) and local management the node has an internationally standardized (ITU-T) Q3 interface. The internal Q3 application in the node as well as the inter-node control channels use IS-IS routing (Intermediate System to Intermediate System routing information exchange protocol for use in conjunction with ISO 8473). The IS-IS protocol is distributed in the system so that all protocol parts are not duplicated in every interface, but some common parts are centralized.
In the Open Systems Interconnection (OSI) model it is possible to manage connections between multiple applications. This means that even if there is only one physical connection between different processes, the connection still may simultaneously serve several parallel transmission services of the applications. The OSI model specifies different layers. The lowest layer (1, Physical Interface) defines the properties of the transmission means. The second layer (2, Data Link; Link-level Logical Interface) defines the end-to-end properties of the connection. The third layer (3, Network; Multi-channel Logical Interface) realizes efficient application of the data link layer (2) e.g. in such a manner that it divides the data link into multiple channels. The next layers are: 4, Transport; 5, Session; and 6, Presentation. The application layer (7, Application; Application Oriented Services) defines the characteristics of the system visible to the user.
FIG. 1
shows blocks of an SDH node. The central block
10
represents centralized and common units (CU) in the node, which include, among others, the node's timing and control units. The CU block realizes functions of different layers, centralized part
1
(CP), upper layers of the communications protocol
2
(symbolically OSI layers 4 to 7), distributed parts
3
(DP, symbolically OSI layers 1 to 3), and drivers
4
(Ethernet driver) for connecting to control systems, for example. The central block further includes optional application software
5
(ASW). Connection blocks
20
,
30
,
40
(STM-1) are examples of functional interfaces in the node that may be optical or electrical wire connections (or interface units STM-4, TU-12, etc.). They include one or more distributed parts
21
,
23
,
24
(DP, layers 1 to 3) and HDLC drivers
22
. The number of distributed parts
21
,
23
,
24
varies according to the requirements of the application. The elements of the central part
10
and the distributed elements
20
,
30
,
40
are connected through a local bus B.
The node described above provides an example of a system located physically in one place. However, as regards the invention, it can just as well be thought that the bus B interconnects nodes and related distributed elements within a wider area. Then the bus can be physically realized in different ways known to a person skilled in the art.
In the SDH system described above, the software stack in the Q3 protocol stack is distributed among several processes, e.g. in block CU and in blocks DP in the STM-1 units. Data communication between the software processes is controlled by means of flow control. In the case depicted in
FIG. 1
the stack processes may be located in blocks CU and DP or in blocks within those blocks, and the processes are physically interconnected by bus B as was mentioned above.
The main function of flow control is to solve data communications problems between asynchronous processes as there may occur situations in which a receiving process is not able to handle the incoming messages quickly enough. Then the process should have a chance to indicate that it cannot at that moment receive new messages but the sending process has to wait until the receiving process has first processed the old messages. In other words, the receiving process must be able to indicate that it is in restraint state. Furthermore, there are situations in which the sending process has a higher priority than the receiving process so that the receiving process cannot refuse new messages even if it could not handle all the messages. Flow control is to ensure that such problems, or restraint states, will not occur but messages are sent to processes only when they can process the messages appropriately.
In general, flow control should be able to provide answers to the following questions:
when will restraint state occur?
how can restraint state be indicated?
what kind of measures should be taken in restraint state?
how to delay the occurrence of restraint state for as long as possible?
how to return to normal state from restraint state?
In the situation depicted in
FIG. 1
, flow control is needed in the following cases:
1) Between IS-IS distributed part and centralized part (DP-CU);
2) Between IS-IS distributed parts (DP-DP);
3) Between distributed part (DP) and upper layer process (OSI layers 4 to 7);
4) Between distributed part
3
and Q3 Ethernet driver
4
, but only from Ethernet driver
4
to distributed part
3
;
5) Between application software ASW and upper layer 2 (OSI layers 4 to 7) processes.
Interface specific flow control is applied to the last two items 4) and 5) since these represent an interface between the stack and other processes. The first three items 1) to 3) represent flow control between stack processes and, as regards flow control, a common approach can be applied to these processes. This invention relates to the flow control in situations represented by items 1), 2) and 3).
Distributed IS-IS parts may physically be located in different units, such as blocks STM-1 and DP in
FIG. 1
, for example. The number of units and processes cannot be determined in advance since the physical equipment is continually expanded and modified during its life-span. This sets special requirements on the flow control mechanism, and as the amount of RAM reserved for flow control is limited it has to be possible to determine the number of queued messages in run time. There is RAM e.g. in all blocks CU and DP shown in
FIG. 1
, some blocks even have it several megabytes, but normally only a few dozens (or only a few) kilobytes are reserved for flow control.
BRIEF SUMMARY OF THE INVENTION
The flow control problems mentioned above are solved according to the invention as characterized by claim 1. Dependent claims describe preferred embodiments of the invention. The invention is advantageously applied in an SDH node.
In accordance with the invention, a so-called credit mechanism is chosen as the flow control algorithm between processes. This means that the sending process has to receive credit from the receiving process before it can send messages to the recipient. To tha
Rautiainen Jari
Tiainen Risto
Tonteri Pekka
George Keith
Nokia Corporation
Pham Chi
Squire, Sander & Dempsey L.L.P.
LandOfFree
Processes in a distributed multiprocessor system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Processes in a distributed multiprocessor system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Processes in a distributed multiprocessor system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3223829