JP3130226B2 - I/O COMMUNICATION SUBSYSTEM AND METHOD - Google Patents

Description

Detailed Description of the Invention

[0001]

FIELD OF THEINVENTION The present invention relates to a data transfer mechanism,
In particular, it relates to multi-channel, user-transparent, unbalanced, dynamically configurable computer input/output channels.

[0002]

2. Description of the Prior Art Mainframe computer systems, such as the IBM S/390, exchange data between I/O devices and main storage through input/output operations collectively known as the channel subsystem.
A channel subsystem is a combination of hardware and software that directs the flow of information between the control units of the I/O devices and main storage, and to the computer central processing unit (CP).
U) from the task of communicating with I/O devices. I/O processing therefore occurs in parallel with normal data processing in the CPU. I/O processing includes path management,
These include testing for path availability, selecting an available channel path, and initiating and terminating the performance of I/O operations by an I/O device. The control unit is the mechanism that translates the characteristics of a particular I/O device into a standard format used by the channel subsystem.

According to conventional I/O operations, a subchannel is dedicated to each I/O device accessed by a channel subsystem. Such subchannels are logical rather than physical transmission paths and are defined in relation to the specific needs of the associated I/O device. The number of such subchannels is limited only by the address size recognized by the computer system.
Thus, according to conventional I/O operations, an I/O device is connected to the channel subsystem by a logical subchannel (called a channel path) derived on the physical transmission medium and activated when an I/O operation is required. A logical subchannel is defined as a transmission mechanism and varies in sized data packet length from 0 to 32 kilobytes in 4 kilobyte steps. An I/O control unit is connected to the channel subsystem by one or more such logical subchannels, and an I/O device is served by one or more control units. Most I/O devices are designed to transfer data at a certain rate and must be served by a logical subchannel at or above this device rate. Although the physical transmission medium operates in half-duplex or full-duplex mode, for simplicity, the logical subchannels have been defined as bidirectional transmissions to support both input and output. The prior art only supported logical transmission subchannels that are equal, balanced, and symmetric for bidirectional transmission. A device is assigned a unique subchannel during installation, and communication on that subchannel follows the communication protocol defined for that type of I/O device. All conventional subchannels are predefined and balanced to correspond to a specific I/O destination,
It is only activated when the system requires I/O. There is a large amount of computer I/O programming that uses the above protocol.

The number of logical subchannels in such systems is independent of the number of channel paths, and the same I/O device may be accessed by many different channel paths represented by a single logical subchannel. A logical subchannel holds storage for main storage addresses where data is read or written, the number of data being transferred, the destination identification, and status information for the attached I/O devices. The status information is accessed by programmed processes. Traditionally, logical subchannels are derived over multi-conductor cables in which multiple bits are transferred in parallel on different copper conductors (byte multiplex mode). Such cables vary in length (30m to 50m) and bandwidth (1.5
This older type of transmission medium is known as a parallel I/O interface, and is referred to as the "IBM System/360 and System/370 I/O Interface."
Interface Channel to Control Unit OEMI "Original"
"Equipment Manufacture Interface" (IBM System Libraries
This is described in detail in regulatory document GA22-6974.

Recently, a new fiber optic medium has become available for interconnecting mainframes with I/O devices. It is a serial I/O interface that supports channel subsystems, has a bandwidth of at least 20 Mbytes/sec, and supports Remote Channel Extender (RCE).
r) Repeaters can be used to transmit signals over tens of kilometers (50 km to 6
One of these types of serial interface channel paths is the ESCON (Enterprise Storage Communication Network).
known as the "International System Connectivity" channel.
BM Enterprise Systems Architecture/390 ESCON I/OI
(IBM System Library document SA22-7202)
The ESCON serial I/O interface uses bursts of serial bit packets (burst mode) and presents problems to standard I/O subchannel systems because of the high capacity bandwidth, delay latencies inherent in the long distances covered by the medium, system integrity (ensuring matching of logical assignments at both ends of the medium), and synchronization problems resulting from variations in these physical parameters.

One fundamental problem in channel subsystems is the inflexibility in defining and activating subchannels.
e) and APPN (Advanced Peer-to-Peer Networks)
In modern applications such as IEEE 802.11b, great flexibility is desired to accommodate both byte multiplex and burst mode transmission paths without being transparent to existing user applications designed when only byte multiplex mode was available. Furthermore, the possibility of splitting long data streams into segments for transmission on different logical subchannels that may be realized on different channel paths adds sequencing problems, especially in the event of a channel path failure. Furthermore, in advanced systems such as SNA and APPN, some degree of dynamic control of input and output subchannel parameters is useful and sometimes necessary. For example, users may need to negotiate available receiver buffer sizes or maximum transmission link capacities. Finally, many modern devices and systems do not require balanced transmission channels with the same capacity in both directions, because many multimedia applications do not involve much control of very wideband multimedia signals.

More specifically, in the past, it was common to provide I/O devices including simple devices such as printers, magnetic tape units, magnetic disk units, terminals and subchannels of other data processing systems. Today, however, such computers communicate with devices over geographic distances connected by long-distance transmission systems such as local area networks or wide area networks. Such interconnection systems have different requirements than simple I/O devices. In particular, as noted above, services such as multimedia distribution require highly unbalanced transmission capabilities in two opposite directions of transmission. Furthermore, it is not always possible to have a given knowledge of the available mechanisms at the other end of a long-distance I/O channel, nor are conventional I/O supervisors prepared to communicate the necessary parameters between the two ends of a subchannel. Some form of system security is also desired to ensure that the two ends of a subchannel have the proper authorization for interconnection. Finally, the need to provide large data paths for retransmission in the event of a channel path failure is required.
The possibility of dividing blocks into segments can create segment and subsegment ordering problems that did not exist in simple single subchannel systems.

Today's channel-attached computer configurations include:
This presents a fundamentally different environment from traditional channel environments, where important aspects of channel system design could be assumed to be geographical proximity, implying a level of local control, whereas today's more dynamic and diverse channel environment creates a number of system design problems.
For example, when distances were limited to a range expressed in meters, it was easy to guarantee channel security and there was little opportunity for external systems to intrude into the system. In contrast, today's channel distances are measured in kilometers. Channel extension techniques extend the distance to connections around the world. Furthermore, traditional systems provided security levels through predefined static definitions. The flexibility of dynamic definitions also increases the exposure to intrusions by external systems.

Another problem in conventional channel systems is the implicit local knowledge of the buffering capacity of the subchannel partners.
Given techniques that are specific to the subchannel partners, assumed values of partner capacity. In case of error, these assumptions can lead to significant system inefficiencies. Similarly, statically predefined transmission directions, i.e., half-duplex or simplex, are often inappropriate for a particular data transfer. Dynamically defined and changeable transmission directions are better suited to today's more flexible data transfer requirements. Finally, user applications typically
Each user interface is designed with a particular device or device type in mind, and the higher user level protocols are adapted to this particular device or device type. This allows each user interface to adapt the user protocols to the channel subsystem.
It requires the implementation of application-specific interfaces. A methodology may replace these existing interfaces by providing a single set of system interfaces.

[0010]

Conventional channel interfaces provide only a balanced bandwidth allocation interface. Such a balanced allocation interface requires that the send or write bandwidth be equal to the receive or read bandwidth. This approach is adequate in traditional transactional or low performance batch environments with inherently balanced data flow.
While entirely desirable, today's client/server environments, by their very nature, impose heavily unbalanced bandwidth interfaces.
Emerging asynchronous transfer mode (ATM) services over wide area networks (WANs) provide an unbalanced network interface.

[0011]

According to an aspect of the present invention,
A multi-path channel (MPC) interface is provided which forms a transparent interface between user applications using conventional I/O channels and conventional channel path I/O supervisor processes in both byte multiplex mode and burst mode transmission paths. More specifically, a new I/O interface is provided which allows user applications to define for their use multi-path channel groups (MPCs) which may include unbalanced transmission capabilities between a computer host and a remote facility. Furthermore, when a data error is detected, the user data is blocked and retransmitted on the same or a different subchannel to take advantage of available transmission subchannels. The divergent delay in the initial transmission is reduced.
y) and error-correcting retransmission of data packets,
A reordering mechanism is provided to ensure proper reconstruction of the data stream. Such retransmissions are particularly problematic when data blocks must be resegmented to accommodate the available smaller capacity subchannels. In accordance with the present invention, such order integrity is maintained by sub-indexing the data blocks that are resegmented for error correction retransmission. In further accordance with the present invention, the normal exchange identification messages between the ends of an I/O subchannel are adapted to the user to dynamically convey information to the other end of the I/O subchannel regarding mechanisms available for processing I/O signals, such as buffer sizes or data link limitations.

In further accordance with the present invention, a "multiple path channel" (MPC) replaces the single subchannel pair (transmit and receive) in conventional device assignment and I/O channel interfaces. A multipath channel is defined as a set of separate transmit and receive paths that together form a logical data transmission pipe. There need not be an equal number of transmit and receive paths, but there must be at least one transmit and one receive path in the set. This set, called a multipath channel, is transparently mapped to the same or different physical channel paths by the multipath channel interface.
No changes to the operation of higher level protocols (such as SNA) are required because a multi-path channel appears to the higher level protocols as a single logical subchannel.

[0013]

1, there is shown a block diagram of a computer I/O system of a computer 21 connected to a host channel and including a user application 10 executing on the computer 21 and requiring further I/O functionality. The computer 21 also includes:
The multipath channel interface 12 controls the input and output of data between the computer 21 and the remote device or system 17 over one or more channel paths 22, 23 or 24.
1 uses adapters 14, 15, 16, 18, 19 and 20 to convert the data signals for transmission over the media 22-24. The multi-path channel interface 12 controls the connection of user data signals from the user application 10 to the media 22-24 by packaging the data into protocol data units (PDUs) appropriate for the channel paths 22-24. The device or system 17 may include simple I/O devices such as a printer, storage system or terminal, or another host computer with which the user application 10 wishes to communicate. The system 17 may further include a gateway to a local or wide area data distribution network having remotely located and connected computers or I/O devices.

More specifically, channel paths 22, 2
3, . . . , 24 are standard byte multiplexed multi-conductor cables over which data blocks are transmitted;
The number of such channel paths may vary from a single half-duplex or full-duplex path to as many as are required or desired to transport the data being transmitted from computer 21. For simplicity, each of channel paths 22-24 is designated by a number
shall be used in half-duplex mode, transmitting in only one direction at a time. The direction of transmission may be reversed, but possible high delay latencies dictate that such reversals be minimized. The modifications required to utilize full-duplex operation of paths 22-24 are believed to be obvious, so
I won't mention it here.

In accordance with the present invention, a multi-path channel interface 12 is connected between the user application 10 and the channel paths 22-24, providing a transparent interconnection between the conventional user application 10 and the conventional channel paths 22-24. This provides the same level of functionality in the modern data transfer environment as was available in the conventional simple and localized systems. More specifically, the Identification Exchange (XI
D) A new set of messages is defined (discussed in conjunction with Figures 5-8) that provides the user with a set of functions that meet the basic system interface requirements, and also provides a set of optional user-defined data fields to implement application-specific requirements, some of which are described below, including system parameter negotiation fields, and user-supplied system verification (security) fields (e.g., encrypted passwords). The exchange of system parameters such as buffering size and control, data flow direction, and high-level user protocol support allows for efficient and rapid I/O data exchange.

Before proceeding with a detailed description of the multipath channel interface 12 of Figure 1, a discussion will be provided of the format of data and control signals transmitted on the transmission paths 22-24 in accordance with the prior art. A diagrammatic representation of a typical transmission block on the transmission paths 22-24 is shown in Figure 2, which includes a transmission block header 25 followed by one or more
One or more Protocol Data Units (PD
The transmission block header 25 includes PDUs 27, 29, each with its own header 26 and 28, respectively. PDU1 27 has PDU header 26, and PDU2 29 has PDU header 28. Details of the headers 25, 26 and 27 are shown in Figure 2 in the dashed connecting blocks below header 25. The transmission block header 25 is shown to include a segment number field 30, which contains a number representing the order of this block among several data blocks transmitted from the same user application 10 to the same destination. The transmission block header 25 further includes a number of control fields 31, which contain information required for various control actions at the remote side, particularly when the transmission block is intended for transmission over a remote packet network system. Control Field 3
Field 1 further includes a flag marking the last segment of a segmented user data block. Field 32 contains the sequence number of the original segment (e.g., the complete transmission block of FIG. 2) that is reblocked into smaller blocks when retransmission is requested after unsuccessful reception of the original block. This sequence number is used to recapture the proper order of the reblocked segments after reception at the remote side of the channel path, as described below.

Each PDU 27, 29, ... has a PDU header, which includes a PDU length field 33 and a PDU
A U flag field 34 is included, where a PDU can contain either user data or MPC control information. One of the flags in field 34 indicates whether the next information is user data or MPC control information. One type of such MPC control signal is the Exchange Identification (XID) signal, which is described in connection with Figures 5-8. Flags are also available in field 34 to indicate the type of data, if desired, and to identify the last PDU in a transmission block. Protocol Identification (ID) field 35
The protocol identification is used to identify the protocol used by the user application from which this data PDU originates. This protocol identification is used by the remote system to identify the protocol used by the user application from which this data PDU originates.
This allows the data to be processed by the appropriate protocol processing, forming a protocol independent subchannel control process for the user application 10 of FIG.
The DU header 26 further includes a sequence number field 36 ;
This is done by multiple P
The control PDU establishes an initial sequence number for the DUs. Such sequence numbers are required for reassembly of disassembled transmission blocks. As described in connection with Figures 8-12, the control PDU may contain an options field that is used by the user application to negotiate variable values for use in blocking and queuing user data.

[0020] Figure 3 shows a detailed block diagram of the multi-path channel interface 12 of Figure 1 which includes three major components: The MPC data manager 45 interfaces with the user applications 10 of Figure 1 and routes data and control streams from the user applications 10 over the available channel paths 22-24.
4. The process includes an outbound data formatting process 46 which converts the data into blocks suitable for transmission over the .
Data manager 45 also controls transmission paths 22 through 24.
an inbound interface that receives data from the remote side and stores them for delivery to the user application 10;
3. The logical subchannels 49-54 shown in FIG. 3 need not be balanced, however, and more or less input channels may be connected to a different number of output channels.

A series of MPC control processes 40 control the data manager 45 and the transmission control processes 48. The processes 40 include a device or system allocation and deallocation process 41 which, in response to control signals from the user applications 10, allocates balanced or unbalanced multipath channels to the user applications. As mentioned above, these multipath channels are simply allocated when the required transmission capacity is available across the channel paths 22-24.
4 (FIG. 1). The path activation and deactivation process 42 of FIG. 3 actually controls the exchange of signals that logically connect the assigned transmission group to the user application. Process 43
detects errors in received transmission data blocks, and typically detects lost segments by indicating lost segment numbers. Error control process 43 also responds to error messages from the remote device or system. Such messages indicate lost or corrupted data segments at the remote device or system. Data retransmission process 44 responds to error control process 43 by:
Retransmitting lost or corrupted data blocks.

While the processes of Figure 3 could be implemented by special purpose circuitry, as would be apparent to one skilled in the art, the processes are preferably implemented by processes programmed on general purpose host computer 21. These processes are described in detail in conjunction with the flow charts of Figures 7-9. The actual programming of these processes would be realized by one skilled in the art of communications programming from the flow charts and the following description.

Figure 4 shows a diagrammatic representation of typical balanced and unbalanced multi-path channels allocated by the multi-path channel interface of Figure 3 in response to a request (allocation of a multi-path channel) of the user application 10 of Figure 1. The user application requests the MP
C12. Such assignments are merely logical reservations and will not be activated until a different CCW (Channel Activate) signal is provided. The Channel Assignment message is
It allows users to specify transmission groups with any combination of subchannels of any size and any direction of transmission. Thus, user applications can specify unbalanced multi-path channel groups in which the size of the read subchannel differs from the size of the write subchannel to accommodate unbalanced applications such as multimedia distribution. One such unbalanced transmission group is shown in FIG.

For comparison, a conventional balanced channel group TG1 62 is shown in Figure 4 and includes a write subchannel 63 and a read subchannel 64, both of which are serviced over a channel path 70. Channel path 70 could, of course, include an OEMI multiplexed byte mode multi-conductor cable transmission medium, an ESCON burst mode fiber optic cable, or other transmission medium.
4, a local user application 60 is assumed to communicate with a remote user application 81 on the other end of transmission paths 70 and 71. A remote multi-path channel interface 72 also serves the remote user 81 in the same manner that the local MPC 61 serves the local user 60.
Figure 4 is therefore completely symmetrical.

Write subchannels 63, 66, 67 and 68 in local MPC 61 are read channels 73, 75, 76 and 77 in remote MPC 72, and read subchannel 64 in local MPC 61 are read channels 75, 76 and 77 in remote MPC 72, respectively.
4 are write channels 74 and 78, respectively, in MPC 72. That is, each logical subchannel is unidirectional. Furthermore, multi-path channel groups 62 and 65 in MPC 61 correspond closely to multi-path channel groups 79 and 80, respectively, in MPC 72. Allocation and activation of the subchannels in FIG. 4 is initiated in both local user application 60 and remote user application 81, and indeed simultaneously in both user applications 60 and 81. A technique for resolving ambiguities that may arise when two ends of a transmission group attempt to allocate or activate a transmission group between them simultaneously is described in conjunction with FIG. 8. A technique for properly maintaining the ordering of data blocks when reblocking data in response to a channel path failure is described in conjunction with FIG. 9.

A user application, such as user application 60 in Figure 4, communicates with a multi-path channel interface, such as interface 61 in Figure 4, by messages. These messages may be used to allocate, activate or deactivate a multi-path channel group, or to transmit data or complete data transmission.
In response to these signals, the MPC 61
(or MPC 72) creates logical multipath channel groups, activates these groups for the actual transmission of data, and notifies users to begin sending data or to begin receiving data.
When a multi-path channel group is no longer needed, the group is deactivated, and when it is no longer valid, the group is deactivated. Communication between MPCs 61 and 72 is effected by Exchange of Identification (XID) signals, which convey the necessary signals to the remote partners to allow or inhibit a transmission path. More specifically, one or more XID control signal blocks are issued on each subchannel of a multi-path channel group to effect activation of that subchannel. When all subchannels of a group have been successfully activated at both ends, the user is signaled to begin transmitting data. In accordance with the invention, these subchannel activation signals include means for activating unbalanced transmission groups and for informing the remote partners of currently available buffer sizes and data link sizes, thereby allowing dynamic modification of transmission group allocations to take advantage of or conform to currently available mechanisms. FIGS. 5 and 6 show how MPCs 61 and 7 of FIG. 4 are used to achieve these results.
1 shows a typical XID message used by 2.
Other XID formats for other purposes are also
As will be apparent to those skilled in the art from the following description, one of the main advantages of the present invention is that a user can easily create an XID format as shown in FIG.
The MPC interface 12 is compliant with the overall requirements of the present invention and can be adapted to achieve a user's specific objectives.

FIG. 5 illustrates a multipath filter as shown in FIG.
FIG. 5 shows a graphical representation of an XID message for activating a particular subchannel of a channel group.
The XID message contains a header field 90 which identifies the local station type, the destination address and the length of the XID message. Field 91 contains the identification of the multi-path channel group to be activated and field 92 contains the status of the multi-path channel group (activated or deactivated). Field 93 contains an identification of the particular user protocol, e.g., the SNA protocol. Field 93 can of course be varied to suit different user protocols (e.g., DECNet or TCP/IP
etc.), in which case different information will be contained and different handling of the XID message will be invoked. The protocol identification field 93 allows the same XID signal structure to be used with different protocols, making the multi-path channel interface of the present invention totally user protocol independent.

Field 94 of the XID message of FIG.
contains the XID status (OK or NG) to aid in correlation of operations at both ends of a transmission group, as will be described in conjunction with FIG. 8. The source address field 95 is
The XID option field 96 identifies the sender to the PC interface and allows this message to be sent via a multipath
5 is transmitted on each subchannel of a transmission group, so that a sending MPC can specify an unbalanced group simply by specifying an unbalanced read or write option in field 97.

The XID activate message of Figure 5 is optionally extended by extension fields shown in Figure 6 if a particular application requires such an extension. In the case depicted in Figure 6, it is assumed that the sending station does not necessarily need to know the size of the receiving buffer. Therefore, the two stations must specify in field 98 of Figure 6 the maximum buffer size available for receiving a block of data. Similarly, field 97 tells the remote station how many consecutive protocol data packets it can receive.
The buffer size and sustained throughput are important parameters in determining the size and frequency of data transmissions on a channel group, and the multipath channel group of FIG.
Among the interfaces, transmission control process 4
Used by 8,

In accordance with the present invention, it will be appreciated that the XID messages of Figures 5 and 6 allow for dynamic negotiation of unbalanced transmission group and specific communication parameters when a transmission group is activated. Furthermore, the ability to format different XID messages corresponding to different user protocols makes the overall operation of the multi-path channel interface of the present invention independent of the protocol of the user application. This protocol independence allows a very wide range of users to utilize the same MPC interface. The XID messages of the present invention
Before going into the detailed flow diagram of the exchange, a brief overview of the process will be given.

The process of allocating and activating a multi-path channel group is initiated in response to a request from a user application 10 of Figure 1. This process is performed in the local MPC interface, but
First, an attempt is made to assign a local communication mechanism to a logical transmission group that satisfies the request. Each logical subchannel is checked for its availability. A physical transmission path is then established to allow the transmission of a First Phase Exchange Identification (XID-1) message between the local MPC interface and the remote MPC interface. The XID-1 message has the format described in connection with Figures 5 and 6 and conveys mandatory and optional information about the requested transmission path. This XID-1 message is repeated and transmitted over each subchannel of the requested multi-path channel group. Meanwhile, at the remote end of the transmission medium, a similar user application is transmitting a message to the remote MPC interface.
C interface, but subject to the specific requirements of the remote user application. Because these requirements may differ from those of the local user application, a specific mechanism is required to negotiate the parameters to be used. A second phase XID exchange (XID-2) is used to resolve these differences. However, conventional protocols do not need to know about multiple XID exchanges and are simply notified to begin data transmission when multiple exchanges have been successfully completed.

At the remote MPC interface, the XID-1 messages received on each subchannel of the transmission group are compared to each other to determine whether they are identical.
The local station verifies that the XID-1 message has been received on each subchannel of the transmission group. The remote MPC interface also checks the size and direction of the requested subchannel to determine whether these features are available at the MPC interface. Meanwhile, the local station does the same with respect to the XID-1 message received from the remote MPC. Both the local and remote MPC interfaces check the received XID-
The system integrity and system security fields in the 1 message are checked. Finally, differences in data processing parameters in the request are resolved by rules defined by the user application. However, typically the buffer size and data link size are always determined to be the lowest required value.
Once the fields of the XID-1 message have been examined and adjusted, both the local and remote MPC interfaces construct tentative XID-2 messages and establish values for the variable option parameters.
XID-1 is generated locally in response to one message.
The random number included in the message determines which MP actually initiates the second phase (XID-2) message exchange.
It is used to determine the C interface.
The PC interface is configured to receive the XID-2 message from other
The constructed XID-2 message is stored until it is received from the PC interface and a comparison can be made.

XID at the receiving MPC interface
-2 If the message is received and successfully verified,
The two XID-2 messages are compared to determine if they are the same. If they are the same, the stored XID
The D-2 message is transmitted to the remote MPC interface where it is checked and compared. Finally, if all checks and comparisons are successful, the two user applications are notified of the successful completion of the identity exchange process and data transmission can commence. If the checks fail at any point in the process, the requested transmission group is dropped and the remote MPC interface is notified to perform a similar process. If the comparison of the XID-2 message fails, the locally generated XID-2 message is used for validation. This process is detailed in relation to Figures 7 and 8.

FIG. 7 illustrates a multipath channel elimination scheme using XID messages similar to those shown in FIGS. 5 and 6.
7 shows a flow diagram of group activation. The process of FIG. 7 must, of course, be performed simultaneously for each subchannel of the requested multi-path channel group. Beginning at start block 110 and continuing through block 111,
Paths are assigned according to requests from user applications. These requests are sent to the balanced or unbalanced multi-path channel groups MPC1 62 and MPC2 65, respectively, in FIG.
The process is for a group. Multiple multi-path channel groups may be requested for allocation and as many as are required are activated. Such an allocation does not actually set up the multi-path channels, but merely selects and ensures the availability of sub-channels of the requested size and direction. Thus, in block 112, the validity of the requested paths is checked. Finally, in block 113, system integrity is checked. As mentioned above, protocol identification fields such as field 93 in FIG. 5 contain security information such as system identification that is checked to determine whether communication is permitted at the remote side, i.e., to ensure that the multi-path channel group requested for a particular remote device or system is permitted under the predetermined access rules. In block 114, the requested transport paths are actually activated, i.e., enabled for transmission.
Of course, it is possible, as is conventional, to statically allocate multi-path channel groups by system declaration and simply activate these pre-established channel groups upon user request.

Once the subchannels of a transmission group have been physically enabled, one or more Exchange of Identification (XID) messages are exchanged between the two ends of each subchannel in preparation for the transmission of user data. As described in connection with Figures 5 and 6, part of this exchange is the user
Deciding on the protocol and buffer size or link size
The purpose of this exchange is to negotiate the desired transmission parameters, such as size, etc. More details of this exchange are provided in connection with the flow diagram of FIG. 8. However, what is important here is that this exchange occurs simultaneously on each subchannel of the requested multi-path channel group to ensure the availability and identification of both ends of the transmission subchannels, as well as the availability and identification of the requested transmission parameters. Decision block 116 determines whether the XID exchange was successfully completed. If not, block 117 determines whether
The user application is notified that the requested channel group will not be activated for data transmission. Block 118 deallocates the transport path established for the XID exchange in block 114 and the process terminates in block 119. This deallocation requires a deallocation message to the remote side of the transmission mechanism to ensure deallocation at the other end. It is also important to note that the activation process represented by the flow chart of Figure 7 may be initiated at either end of the transmission group and is initiated simultaneously at both ends of the transmission group.

If block 116 determines that the XID exchange has been successfully completed, then block 120 starts the transport control process 4 of the MPC interface of FIG.
Block 121 then initiates the MPC Data Manager 45 (FIG. 3) to reflect the requested or negotiated size of the data queue 47 as well as the required data formatting 46.
In block 22, the desired transmission direction for a particular transmission subchannel is assigned, and in block 123, the transmission block size for this subchannel is selected, where blocks 122 and 123 represent the dynamic assignment of both the transmission direction and the subchannel capacity at activation time.
This is a significant departure from the prior art where both the transmission direction and subchannel size are statically determined and are simply activated upon user request. The MPC interface process initialization is initiated in response to successful completion of an XID exchange:
Importantly, this occurs simultaneously at the remote MPC interface.

Once all of the subchannel variables have been selected and implemented, the user application is notified of the availability of the requested multi-path channel group at block 124. The user application actually transfers the data to the remote location over the assigned and activated channel group at block 125. The process of FIG. 7 then ends at block 119.
Although not explicitly shown here, multipath transmission is also possible when a data transmission is completed or when a transmission failure occurs.
To deactivate or deallocate a channel group, a process very similar to that shown in FIG. 7 is used.

Referring to FIG. 8, block 115 of FIG.
A detailed flow diagram of the XID message exchange process that occurs in the process block 13 is shown in FIG.
Starting at 0, a user request for a multi-path channel group is received at block 131. Note that this request is received simultaneously at the multi-path channel interfaces (FIG. 3) at both ends of the channel group. This simultaneous issuance is the most difficult case, and in the flow diagram of FIG. 8, it is assumed that the MPCs at both ends of the transmission group simultaneously request activation of the multi-path channel group. At block 132, X
The ID-1 message format is generated. For convenience, the XID message format is as shown in Figures 5 and 6. As will be apparent to those skilled in the art, other XID message formats may be used in accordance with different user applications.

More specifically, in block 132:
The transmission size is set in field 98, as is the data flow direction in field 97. If necessary, appropriate system security information is set in fields 90 and 91 of FIG.
1, and in fields 31 and 35 of the header of FIG. 2. To resolve ambiguities that may arise from simultaneous issuance of XID-1 messages at the MPCs of the two ends of a multi-path channel group, an ambiguity resolution signal is introduced in the sequence number field 30 of the header of FIG. 2. The ambiguity resolution signal is a randomly generated number in the illustrated embodiment. This random number is used at the remote MPC interface to select the XID-1 message that controls the second phase activation process. Another method of resolving such ambiguities uses a predefined table that indicates the ranking of available terminal pairs at the two ends of each multi-path channel group.

Following the generation of the XID-1 message in block 132, the XID message is sent to the remote MPC interface on each subchannel in the assigned multi-path channel group in block 133. This XID-1 message is received at the remote MPC interface in block 134, and the parameters in the XID-1 message are examined in block 136; that is, the system integrity signal is used to ensure system integrity, the transmission direction and size of the subchannel are used to ensure availability of the subchannel, and the buffer parameters are used to determine whether these mechanisms are available. A second phase XID-2 message format is then generated in block 136 for transmission back to the local MPC interface. The format and field contents of the XID-2 message are identical to that of the XID-1 message, except for the variable buffer size parameter, which is changed to reflect the actual availability of these mechanisms. Decision block 137 determines whether the data in the XID-1 message received from the remote MPC interface is valid. Block 1
If all three checks in block 135 are successful, then the phase 2 XID-2 message is marked in field 94 (FIG. 5) as "OK" in block 139. If any check in block 135 fails, then the phase 2 XID-2 message is marked in field 94 as "NG (no go)".
Whether the received XID-1 message is valid or invalid, control proceeds to decision block 140,
Segment number field 30 of the received XID-1 header
(Figure 2) is a random number generated by a locally issued XID
The received random number is compared to the random number generated in response to the -1 message. If the received random number is greater than the value of the locally generated random number, control passes to block 141 where the remote MPC interface waits for a second phase XID-2 message to be received from the remote MPC interface. Once this response is received, control passes to decision block 142.
The received phase 2 XID-2 message is then examined in the same manner as the original XID-1 message was examined in block 135 .

If the received XID-2 message is identical to the locally generated XID-2 message, the locally generated XID-2 signal is marked "OK" at block 143 and sent to the remote MPC interface at block 144, completing the verification process. If the random number is less than the locally generated XID-1 message, or
Alternatively, if the check on the received XID-2 message fails at decision block 142, control passes to block 148 where the XID
The -2 message is marked as "NG" and control is passed to block 144 which sends the XID-2 message to the remote MPC interface. Decision block 145 then determines whether both the locally and remotely generated XID-2 messages are OK. If so, control is passed to block 146 which returns the XID-2 message.
8. notifies the user to begin transmitting user data. If not OK, block 148 activates the failure procedure described in connection with Figure 7. In either event, control then passes to end block 147 which ends the XID exchange process of Figure 8 and returns to the process of Figure 7.

Although only two exchanges of XID messages have been described in connection with FIG. 8, it will be apparent that if no parameters need to be negotiated in this transmission group, then only one exchange would suffice. Similarly, if two or more interdependent parameters need to be negotiated prior to the start of data transmission, three or more XID exchanges can be used to effect these negotiations.
Such extensions of the ID exchange process will be apparent to those skilled in the art and will not be described here.

Referring to FIG. 9, the data
A flow diagram for sub-indexing a segment is shown. Beginning at block 150, a local data block is read at block 151 at a local MPC interface, such as interface 12 of FIG. 1 (shown in detail in FIG. 3).
The XID message exchange between the local MPC interface 61 (FIG. 4) and the remote MPC interface 72 has already been started.
9, all subchannels 66-69 of FIG. 2 (65-80) have been successfully executed. For the purposes of the flow diagram of FIG. 9, write subchannels C and D (66-69 of FIG. 4)
4, 75 and 67-76) have a capacity of 4 kilobytes and therefore take only data segments with a maximum length of 4 kilobytes.
-77) has a capacity of 16 kilobytes, and therefore takes data segments up to 16 kilobytes long. In FIG. 9, the block to the left of the dashed line is the local MPC
The blocks to the right of the dashed line are implemented in remote MPC interface 72. These functions are of course implemented symmetrically in the opposite direction of transmission.

Referring to FIG. 9, block 152 formats 16 kilobyte segments of data to be transmitted on path E, and blocks 153 and 154
Each of these formats a 4 kilobyte segment of data transmitted on paths D and C, respectively. In FIG. 9, the 4 kilobyte segments transmitted on paths C and D are represented by blocks 155 and 156, respectively.
Assume, however, that the 16 kilobyte segment transmitted on path E (e.g., channel path 70 in FIG. 4) is successfully received at the remote MPC of
157 in the remote MPC interface.
When block 157 detects that a segment transmitted on path E has been lost, block 158 detects that a segment transmitted on path E has been lost.
At the PC interface, deallocate path E. Due to the occurrence of a failure in path E, it is important to remove this path from service not only for this multi-path channel group, but for all previously defined channel groups.

The channel designated in FIG. 4 as channel B (74-64 in FIG. 4) indicates the path failure in accordance with a conventional fault detection system and provides an error status identifying path E. In response to this failure message, block 173 in the local MPC interface detects that path E has failed.
Also in response to a failure message,
Retransmit block 161 is activated and the lost data segment is retransmitted to the remote MPC interface. However, if 16 kilobyte subchannel E is no longer available in transmission group MPC2, then 1
The 6 kilobyte data segment must be divided into 4 kilobyte data segments for transmission over the two available 4 kilobyte subchannels identified as paths C and D. In accordance with the present invention, the four 4 kilobyte subsegments are divided into the original 16 kilobyte data segments at blocks 162, 163, 164 and 165.
Each of these 4 kilobyte subsegments has a segment number appended to field 32 of the transmission block header 25 (FIG. 2).

The three data segments formed in blocks 152, 153 and 154 are the headers 2 of the data transmission blocks carrying these data segments.
Note that field 30 of item 5 contains sequence numbers. The purpose of these sequence numbers in field 30 is to:
If these data segments were transferred to the remote MPC interface in any other order due to delay idiosyncrasies of the variable physical channel paths through which the subchannels are derived,
The segment numbers of the retransmission blocks of blocks 162-165 serve the same function for the resegmented and retransmitted data segments. That is, if the four subsegments generated by blocks 162-165 arrive at the remote MPC interface in some order other than the original transmission order, the segment numbers allow the remote MPC interface to reassemble these data segments in the proper order.
The PC interface reassembles the subsegments in the proper order for delivery to the ultimate user, therefore the original sequence numbers must be preserved in sequence number field 30 (FIG. 2) to ensure proper ordering of the original segments.

In segmented data transmission,
The sequence numbers used to properly sequence the segments are sometimes called segment indexes, and the process is called segment indexing. Thus, the second level of indexing described above is a sub-indexing of the resegmented data segments that are retransmitted.
9 (b-indexing). Once the retransmitted resegmented data subsegments have all been successfully received by blocks 166-169 at the remote MPC interface, the sequence numbers are used in block 170 to reconstruct the original three segments. At the same time, the sequence numbers of the resegmented retransmitted subsegments of the 16 kilobyte segment formed in block 152 and resegmented in blocks 162-165 are used in block 170 to reconstruct from these subsegments a new 16 kilobyte segment, i.e., the original data block. The reconstructed data block is then delivered in block 171 to the remote user application and the process of FIG. 9 terminates in block 172.

In summary, the following is disclosed regarding the configuration of the present invention:

(1) General Purpose Digital Computer
an input/output communications subsystem for a system, comprising at least one user interface executing on said computer system and operating according to a predetermined communications protocol;
An I/O communications subsystem comprising an application, at least one I/O device or system with which said computer system desires to communicate, an I/O transmission means connected between said computer system and said I/O device or system, means for defining a plurality of independent unidirectional logical subchannels for transmission in one or opposite directions on said transmission means, and means responsive to said user application for assigning and activating to said user application a group of said subchannels having an unbalanced number of said subchannels in two directions of transmission on said transmission means. (2) An I/O communications subsystem as described in (1), comprising means for activating individual said logical subchannels of said subchannel group, and means for specifying a size of each of said subchannels in each of said activation means. (3) An I/O communications subsystem as described in (1), comprising means for activating individual said logical subchannels of said subchannel group, and means for specifying a transmission direction of each of said subchannels in each of said activation means. (4) An I/O communications subsystem as described in (1), comprising means for identifying said predetermined transmission protocol such that said I/O communications subsystem operates independent of said predetermined transmission protocol. (5) A method of controlling I/O communications between a computer system and an I/O device or system, comprising the steps of: executing at least one user application on said computer system and operating according to a predetermined communications protocol; communicating I/O data between at least one I/O device or system and said computer system; connecting an I/O transmission control means between said computer system and said I/O device or system; defining a plurality of independent unidirectional logical subchannels for transmission in one or opposite directions between said computer system and said I/O device or system; and, in response to said user application, allocating and activating to said user application a group of said subchannels having an unbalanced number of said subchannels in two directions of transmission between said computer system and said I/O device or system. (6) The method of (5) above, further comprising the steps of: activating each of said logical subchannels of said subchannel group; and specifying a size of each of said subchannels in said activating step. 7. The method of claim 5, further comprising the steps of: activating each of said logical subchannels of said subchannel group; and specifying a transmission direction for each of said subchannels in said activating step. 8. The method of claim 5, further comprising the steps of identifying said predetermined transmission protocol such that said I/O device or system operates independently of said predetermined transmission protocol.

[0048]

As described above, according to the present invention,
A multipath channel interface is provided which forms a transparent interface between user applications using conventional I/O channels and conventional channel path I/O supervisor processes in both byte multiplexed and burst mode transmission paths.

[Brief description of the drawings]

FIG. 1 is a general block diagram of a computer input/output system in which the multi-path channel interface of the present invention is used.

2 is a diagram illustrating the structure of a transmission block used in communicating input/output data and control signals in the system of FIG. 1 according to the present invention;

3 is a detailed block diagram illustrating the architecture of the multi-path channel interface of FIG. 1;

FIG. 4 illustrates an exemplary multi-path channel configuration that may be created and utilized by the multi-path channel interface of the present invention.

FIG. 5 shows a multipath channel interface according to the present invention for a VT in an SNA packet network.
FIG. 2 illustrates a typical Exchange of Identification (XID) control signal format that may be used for communication with a control device such as an AM.

6 illustrates an optional extension of the XID control signal format shown in FIG. 5 to indicate the maximum available read buffer size at the receiving side of an I/O transfer.

7 is a detailed flow diagram of a subchannel activation process used by the multi-channel interface of FIG. 3 in accordance with the present invention.

8 is a detailed flow diagram of an exchange of identification (XID) signals used in the activation process of FIG.

9 illustrates the multipath channel block diagram of FIG. 3 used in accordance with the present invention when a retransmission of a data segment must be performed on a subchannel having a lower capacity than the capacity of the channel on which the original transmission of the segment occurred.
13 is a detailed flow diagram of an interface segment sub-indexing process.

[Explanation of symbols]

10 User Application 12 Multipath Channel Interface 13 Communications Supervisor 14, 15, 16, 18, 19, 20 Adapter 17 Remote Device or System 21 Computer 22, 23, 24 Channel Bus 25 Transmission Block Header 26, 28 PDU Header 27 Protocol Data Unit (PDU) 1 29 Protocol Data Unit (PDU) 2 30 Segment Number Field 31 Control Field 32, 92, 94, 97, 98 Field 33 PDU Length Field 34 PDU Flags Field 35 Protocol Identification (ID) Field 36 Sequence Number Field 40 MPC Control Process 41 Device or System Allocation and Deallocation Process 42 Path Activation and Deactivation Process 43 Error Control Process 45 MPC Data Manager 46 Outbound Data Formatting Process 48 Multipath Channel Interface Transmission Control Subsystem 49, 50, 51, 52, 53, 54 Logical I/O Subchannel 61 Local MPC Interface 62 Balanced Channel Group 63, 66, 67, 68 Write Subchannel 72 Remote MPC Interface 73, 75, 76, 77 Read Channel 90 Header Field 93 Protocol Identification Field 95 Source Address Field 96 XID Option Field

───────────────────────────────────────────────────────── Continued from the front page (72) Inventor Louis Frank Mendit 4701 Tanglewood Drive, Raleigh, North Carolina 27612, USA (72) Inventor Arthur James Stagg 12613 Waterman Drive, Raleigh, North Carolina 12714, USA (56) References JP 4-251360 (JP, A) JP 4-88455 (JP, A) JP 58-158732 (JP, A) JP 57-212534 (JP, A) (58) Field of investigation (Int.Cl. ⁷ , DB name) G06F 13/12 G06F 13/00

Claims (8)

(57) [Claims] [Claim 1] An input/output communications subsystem for a general purpose digital computer system, comprising: at least one user application executing on said computer system and operating according to a predetermined communications protocol; at least one input/output device or system with which said computer system wishes to communicate; input/output transmission means connected between said computer system and said input/output device or system; means for defining a plurality of independent unidirectional logical subchannels for transmission in one or opposite directions on said transmission means; and means for, in response to said user application, transmitting to said user application a plurality of independent unidirectional logical subchannels on said transmission means.
and means for allocating and activating groups of said subchannels having unbalanced numbers of said subchannels in one direction of transmission. 2. The input/output communications subsystem of claim 1, further comprising: means for activating each of said logical subchannels of said subchannel group; and means for specifying, in each of said activating means, a size of each of said subchannels. 3. The input/output communications subsystem of claim 1, further comprising: means for activating each of said logical subchannels of said subchannel group; and means for specifying, within each of said activating means, a transmission direction for each of said subchannels. 4. The input/output communications subsystem of claim 1, further comprising: means for identifying said predetermined transmission protocol such that said input/output communications subsystem operates independent of said predetermined transmission protocol. 5. A method of controlling input/output communications between a computer system and an input/output device or system, comprising the steps of: executing at least one user application on said computer system and operating according to a predetermined communications protocol; communicating input/output data between at least one input/output device or system and said computer system; connecting an input/output transmission control means between said computer system and said input/output device or system; and connecting an input/output transmission control means between said computer system and said input/output device or system for transmission in one direction or in the opposite direction between said computer system and said input/output device or system.
defining a plurality of independent unidirectional logical subchannels; and, in response to said user application, allocating and activating to said user application a group of said subchannels having an unbalanced number of said subchannels in two directions of transmission between said computer system and said I/O device or system. 6. The method of claim 5, further comprising the steps of: activating each of said logical subchannels of said subchannel group; and specifying a size of each of said subchannels during said activating step. 7. The method of claim 5, further comprising the steps of: activating each of said logical subchannels of said subchannel group; and specifying a transmission direction for each of said subchannels during said activating step. 8. The method of claim 5, further comprising the step of identifying said predetermined transmission protocol such that said I/O device or system operates independent of said predetermined transmission protocol.