Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing
Reexamination Certificate
1998-07-31
2001-05-15
Vu, Viet D. (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
C709S227000, C709S250000, C709S241000, C709S241000
Reexamination Certificate
active
06233619
ABSTRACT:
BACKGROUND
1. Field of the Invention
The present invention relates to the field of computer networking, and, more particularly, to apparatus and methods for allowing two closely coupled heterogeneous computer systems to communicate with each other via a messaging system over an interconnection including a simulated or “virtual” transport layer interface.
2. Description of the Prior Art
The ability for heterogeneous computer systems to communicate with each other over a network using standard ISO and/or proprietary networking protocols is known. Most computer systems have some form of networking architecture that enables the computer system to perform networking in accordance with those protocols. For example, the generic networking platform with the standard 7 layer ISO Reference Model includes a network stack: applications, presentation, and sessions levels under user control, and transport, network, data link, and physical levels under kernel (operating system) control. Typical networking architectures comprise both system software and hardware.
FIG. 1
is a block diagram illustrating the components of a networking architecture employed by a Unisys A Series enterprise server
10
in order to communicate with other hosts, or nodes, on a network
15
. The A Series enterprise server
10
executes the Unisys MCP operating system
12
, and has an I/O subsystem that comprises one or more I/O Modules (IOM)
14
housed within the A Series chassis. The IOM
14
implements a Unisys proprietary I/O bus architecture referred to as CS-BUS II or CS-Bus III (hereinafter “the CS Bus”). A plurality of card slots, e.g. slots
16
a-d
, are provided for connecting interface cards, referred to as “channel adapters”, into the CS Bus. Different groups, or racks, of channel adapter slots are each controlled by a Channel Manager Unit (CMU) (e.g., CMUs
18
a
,
18
b
). An IOM can contain several CMUs, each of which controls a different rack of channel adapter card slots via the CS-Bus. The CMUs manage the physical and data layers of the CS-Bus data transfer protocol.
Channel adapter cards, which each may occupy one or more channel adapter card slots within the IOM
14
, provide various connectivity solutions for the A Series enterprise server
10
. For example, Unisys provides a channel adapter card that implements the Small Computer System Interface(SCSI) protocol for connecting SCSI peripherals to the enterprise server
10
.
For network connectivity, Unisys provides several channel adapters to support various physical networking protocols. These channel adapters are generally referred to as network processors (NP). For example, Unisys ICP22 and ICP26 network processors are channel adapter cards that implement the Ethernet network protocol and can be used to connect an A Series enterprise server
10
to an Ethernet network. Unisys also provides network processors for connectivity to FDDI and ATM networks. As shown in
FIG. 1
, a number of different network processors (e.g., NPs
20
a
,
20
b
, and
20
c
) can be installed in respective channel adapter slots (e.g., slots
16
b
,
16
c
, and
16
d
) of the IOM
14
, in order to provide different network connectivity solutions.
As shown in the more detailed view of network processor
20
c
(installed in channel adapter slot
16
d
), a network processor may comprise a plurality of different lines, e.g., Line
0
, Line
1
. . . LineN, where a line represents a physical endpoint within a network. For example, the Unisys ICP22 network processor has two lines, each of which comprises a separate Ethernet connection—one line could be connected to one Ethernet network, and the other to a different Ethernet network.
Each line of a network processor can have one station group defined on that line. A station group consists of one or more stations. A station is a logical endpoint that represents a logical dialog on that line. Thus, more than one logical dialog can take place over a given line of a network processor. This is achieved through multiplexing. For example, with a connection-oriented networking protocol, such as the Burroughs Network Architecture—Version 2 protocol (BNAv2), one station may represent a logical dialog with one other BNAv2 host on the network, whereas another station may represent a logical dialog to a different BNAv2 host. As illustrated in
FIG. 1
, for example, Station
0
of LineN may represent a logical dialog with BNAv2 host
22
, and Stationl of LineN may represent a logical dialog with BNAv2 host
24
. For networking protocols that are not connection-oriented, like the Internet Protocol (IP), only one station needs to be defined to handle all communications for that protocol stack. For example, in
FIG. 1
, StationN of LineN could be defined as the logical endpoint for all IP traffic over LineN. A Local Area Network Station Group (LANSG) module
26
, which comprises software executing on the network processor
20
c
, provides callable procedures for creating and maintaining stations and station groups on the various lines of the network processor
20
d
and for sending and receiving data over them.
Other software components that execute on the network processor
20
c
include a Queue Service Provider (QSP) module
28
, which handles the passing of messages between the NP Support
40
and the channel adapters. QSP module
28
also multiplexes and demultiplexes data for all stations defined on a given NP. Some data is blocked together for efficiency; other data is not. Other components include two stub modules—a Network Services Manager stub (NSM-stub)
30
and a Link Layer Manager stub (LLM-stub)
32
—which interface with corresponding modules of a Core Network Services (CNS) software component
34
, to and from modules within the MCP environment.
Generally, a network processor (e.g., NP
20
a
,
20
b
, or
20
c
) implements the data link and physical layers of the 7-layer ISO Reference Model. Higher level networking protocols that a client application
46
may wish to employ in order to communicate with applications running on different hosts of the network
15
, such as the BNAv2 and TCP/IP networking protocols, are implemented as network protocol providers on the A Series system
10
. A network protocol provider is a software module that implements these higher level networking protocols. For example, Unisys provides both BNAv2 Host Resident Network Provider (HRNP) modules and TCP/IP HRNP modules. In the example of
FIG. 1
, a BNAv2 HRNP
42
and a TCP/IP HRNP
44
are shown.
The Core Network Services (CNS) software
34
provides support for the network protocol providers
42
,
44
and handles the initialization and maintenance of network processors and the station groups defined thereon. Specifically, CNS
34
comprises a Network Services Manager (NSM)
36
that initializes and manages the network processors (e.g.,
20
a
,
20
b
,
20
c
) installed in the system, and a Link Layer Manager (LLM)
38
that initializes and maintains the identity and attributes of each station group defined on a given network processor. Another component (not shown) of CNS
34
validates attributes associated with station groups and stations created on a network processor. These attributes are passed between the network processor and CNS
34
via a control dialog when the stations are defined. Like the stub procedures for the NSM and LLM modules
36
,
38
, network processors also have a stub procedure (LLAH, not shown) that corresponds to the attribute handler of CNS
34
. An NPSUPPORT software library
40
, as well as portions of the MCP operating system
12
, provide routines and procedure calls that serve as an interface between a network processor and the CNS
34
and network protocol providers
42
,
44
, and control loading of software to the NPs and dumping of their state.
Each network processor has an associated identifier that uniquely identifies that network processor within the system
10
. When a network processor is initialized and brought on-line, the NSM-stub
30
in the network processor interfaces with the NSM
36
of CNS
34
via a
Coyne Lois B.
Jennion Susan
Kain Michael T.
Narisi Anthony
Salamon Gary
Adornato Rocco L.
Starr Mark T.
Unisys Corporation
Vu Viet D.
Woodcock Washburn Kurtz Mackiewicz & Norris LLP
LandOfFree
Virtual transport layer interface and messaging subsystem... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Virtual transport layer interface and messaging subsystem..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Virtual transport layer interface and messaging subsystem... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2541679