A node within a network comprising a transport layer protocol for multicasting datagrams on a virtual ring. Each node on the virtual ring is logically connected to two neighbour nodes through virtual connections. A virtual ring datagram is sent to a downstream neighbour node on the virtual ring and a token is received. The virtual ring is identified and the token is forwarded to the downstream neighbour node. If the received datagram is a virtual ring datagram, the virtual ring is identified and the node originator of the received virtual ring datagram is checked. If the received virtual ring datagram has not been locally originated, data in the virtual ring datagram is processed and the virtual ring datagram is forwarded to the downstream neighbour node on the virtual ring. If the received virtual ring datagram has been locally originated, the virtual ring datagram is removed from the virtual ring.
|
14. A computer network comprising:
at least two nodes having a transport layer protocol to provide end to end data transfer to multicast datagrams in a virtual ring, each datagram including a virtual ring identifier, a source address of a sending node, a destination address of a next node on the ring, a source port, a destination port, and an identifier for a node originator of the datagram;
each node on said virtual ring being logically connected to an upstream neighbor node and a downstream neighbor node through virtual connection; and
instructions for multicasting datagrams on said virtual ring comprising:
sending a datagram to the downstream neighbor node on the virtual ring;
identifying the received datagram upon receipt of the datagram;
determining if the received datagram is a token generated by a virtual ring manager, wherein the token comprises a sequence number incremented each time the token is received by the virtual ring manager node, responsible for validating and modifying a virtual ring topology and forwarding the token to the downstream neighbor node on the identified virtual ring if the token is valid;
determining if the received datagram is a virtual ring datagram containing data other than a token;
forwarding said virtual ring datagram to the downstream neighbor node on the identified virtual ring if the received virtual ring datagram has not been locally originated; and
removing the virtual ring datagram from the virtual ring if the received virtual ring datagram has been locally originated.
1. A method to use in a node within a network comprising a transport layer protocol providing end to end data transfer, for multicasting datagrams on a virtual ring, each node on the virtual ring being logically connected according to the network transport layer protocol to an upstream neighbor node and a downstream neighbor node through virtual connections, comprising:
sending a datagram to the downstream neighbor node on the virtual ring, said datagram including a virtual ring identifier, a source address of a sending node, a destination address of a next node on the ring, a source port, a destination port, and an identifier for a node originator of the datagram;
each node including said ring identifier;
identifying the received datagram upon receipt of the datagram;
determining if the received datagram is a token generated by a virtual ring manager, wherein the token comprises a sequence number incremented each time the token is received by the virtual ring manager node, and forwarding the token to the downstream neighbor node on the identified virtual ring if the token is valid, wherein said manager is responsible for validating and modifying a ring topology;
determining if the received datagram is a virtual ring datagram containing data other than a token;
forwarding said virtual ring datagram to the downstream neighbor node on the identified virtual ring if the received virtual ring datagram has not been locally originated; and
removing the virtual ring datagram from the virtual ring if the received virtual ring datagram has been locally originated.
16. A method to use in a node within a network comprising a transport layer protocol providing end to end data transfer, for multicasting datagrams on a virtual ring, each node on the virtual ring being logically connected according to the network transport layer protocol to an upstream neighbor node and a downstream neighbor node through virtual connections, comprising;
sending a datagram to the downstream neighbor node on the virtual ring; said datagram comprising:
a virtual ring identifier;
means for identifying the node originator of the datagram;
a destination address of a next node on the ring; and
data;
identifying the received datagram upon receipt of the datagram;
determining if the received datagram is a token generated by a virtual ring manager responsible for validating and modifying a ring topology, comprising:
identifying the virtual ring; checking whether the token is valid; and
forwarding the token to the downstream neighbor node on the identified virtual ring if the token is valid, said token being a datagram including a token identifier and a token sequence number;
determining if the received datagram is a virtual ring datagram containing data other than a token, comprising:
identifying the virtual ring;
checking the node originator of the received virtual ring datagram;
determining if the received virtual ring datagram has not been locally originated, comprising:
processing data comprised in said virtual ring datagram and forwarding said virtual ring datagram to the downstream neighbor node on the identified virtual ring; and determining if the received virtual ring datagram has been locally originated, comprising:
removing the virtual ring datagram from the virtual ring.
15. An article comprising:
a computer network comprising at least two nodes having a transport layer protocol to provide end to end data transfer to multicast datagrams in a virtual ring; each node on said virtual ring being logically connected to an upstream neighbor node and a downstream neighbor node through virtual connection;
a non-transitory computer readable medium in said network;
instructions in said medium for multicasting datagrams on said virtual ring comprising:
instructions for sending a datagram to the downstream neighbor node on the virtual ring;
instructions for identifying the received datagram upon receipt of the datagram;
instructions for determining if the received datagram is a token generated by a virtual ring manager responsible for validating and modifying a virtual ring topology, and forwarding the token to the downstream neighbor node on the identified virtual ring if the token is valid, said token being a datagram including a token identifier and a token sequence number, a source address of a sending node, a source port, a destination port, and a destination address of a next node on the ring, and means for identifying the virtual ring, wherein the sequence number is incremented each time the token is received by the virtual ring manager node;
instructions for determining if the received datagram is a virtual ring datagram containing data other than a token;
instructions for forwarding said virtual ring datagram to the downstream neighbor node on the identified virtual ring if the received virtual ring diagram has not been local originated; and
instructions for removing the virtual ring datagram from the virtual ring if the received virtual ring datagram has been locally originated.
2. The method of
3. The method according to
4. The method of
5. The method of
maintaining and updating:
means for identifying the virtual ring;
an address of the upstream neighbor node;
an address of the downstream neighbor node; and
an address of the virtual ring manager; and
optionally maintaining and updating an address of a backup virtual ring manager.
6. The method of
starting a timer and waiting for a return of the token; and
executing a recovery procedure when the timer expires, wherein receipt of a token comprises stopping the timer.
7. The method of
a computer system routing datagrams in the network, and a computer system exchanging datagrams on the network.
8. The method of
generating a token;
setting a token sequence number of said token to an initial value;
forwarding said token to the downstream neighbor node on the virtual ring, comprising:
incrementing the token sequence number; and executing a recovery procedure when a timer expires comprising:
generating a new token; and
forwarding said token to the downstream neighbor node on the virtual ring.
9. The method of
sending to a virtual ring node manager node previously defined on the virtual ring, an insertion request message comprising an address of the node; and means for identifying the virtual ring; and
receiving an insertion confirmation message from the virtual ring manager node comprising an address of an upstream neighbor node; and an address of a downstream neighbor node.
10. The method of
sending an insertion request message comprising:
the address of the node; and
means for identifying the virtual ring to a backup ring manager node previously defined on the virtual ring;
restarting the insertion timer;
receiving an insertion confirmation message from the backup virtual ring manager comprising:
the address of an upstream neighbor node;
the address of a downstream neighbor node; and
stopping the insertion timer.
11. The method of
sending to a virtual ring manager node previously defined on the virtual ring, a removal request message comprising:
an address of the upstream neighbor node;
an address of the downstream neighbor node; and
an address of the node; and
receiving a removal confirmation message from the virtual ring manager.
12. The method of
sending to a backup ring manager node previously defined on the virtual ring, a removal request message, comprising:
the address of the upstream neighbor node;
the address of the downstream neighbor node; and
the address of the node;
restarting the removal timer;
receiving a removal confirmation message from the backup virtual ring manager; and
stopping the removal timer.
13. The method according to
receiving from a virtual ring manager node defined on the virtual ring, a change neighbor message comprising an address selected from a group consisting of: an address of a new upstream neighbor node, an address of a new downstream neighbor node, and combinations thereof;
maintaining an address selected from a group consisting of: the address of the new upstream neighbor node, the address of the new downstream neighbor node, and combinations thereof; and
sending to the virtual ring manager node a neighbor change confirmation message.
|
|||||||||||||||||||||||||||||||||||||||
The present invention relates to communication on digital networks, and more particularly to a system and a method for creating a virtual ring between nodes in a an Internet Protocol (IP) network and for multicasting datagrams to nodes part of this virtual ring.
In the present description, the term “Network” designates an ordinary network, based on the Internet Protocol (IP) technology. This network can be a Local Area Network (LAN), but also an Enterprise (private) Intranet or even the (public) Internet. The term “Node” designates the computer systems in the network routing the communications, such as routers, and, also, the computer systems exchanging information on the network, such as workstations and servers.
In a network, nodes must be able to exchange information with other nodes of a same group. For instance, the broadcast of a same information to multiple nodes located in different locations is called “Multicast”. In a group of N nodes called a Multicast group as illustrated in
If a node, within a group of N nodes, wants to communicate information to all the other nodes of its group, it requires N−1 TCP sessions. If all the nodes need to communicate together in a full mesh configuration, N×(N−1)/2 TCP sessions are required. It is important to note that since a TCP session is bidirectional, the required number of sessions is N×(N−1)/2 and not N×(N−1).
The number of sessions can be considerable in a network comprising hundreds or thousands of nodes. It can results an important overhead with a significant impact in term of bandwidth consumption in the network and resource (data processing and memory) utilization in each node. In each node, the establishment the TCP sessions requires data processing resources and the maintenance of these TCP sessions requires memory in particular to store the context of the TCP sessions (TCP Control Block).
In absence of synchronisation at the application level, the nodes can exchange the same piece of information on all the TCP sessions at the same time (communication any to any). This is bandwidth consuming at the network level and resource consuming at the level of each node. An example of this scenario is the exchange of routing information between routers. Each router broadcast routing information to the other routers either periodically or when a change occurs, depending on the routing protocol used in the network. Another example is the synchronisation of multiple servers in a distributed database.
Several solutions exist to limit the number of sessions between nodes. A solution illustrated in
Note, the central node (200) is connected to all other nodes including the backup central node (201). The result is the establishment of N−1 TCP sessions. The addition of a second star configuration based on the backup central node (201) requires another N−1 TCP sessions. However, since a TCP session already exists between central node (200) and backup central node (201), this session does not need to be duplicated. In conclusion, the number of sessions required in a dual star configuration is (N−1)+(N−2)=2×N−3
Accordingly, it is an object of the invention to reduce bandwidth utilization in an IP network comprising inter-communicating nodes, to reduce the resource consumption of inter-communicating nodes, and to define several groups of inter-communicating nodes in an IP network.
This invention comprises a method and system for communicating among nodes in a virtual ring through a transport layer protocol.
In one aspect of the invention, a method is provided for connecting nodes in a virtual ring and for providing data transfer between the nodes. Each node in the virtual ring is logically connected according to network transport layer protocol to an upstream neighbor node and a downstream neighbor node. Datagrams are multicasted on the virtual ring by sending a virtual ring datagram to the downstream neighbor node on the virtual ring. The received datagram is identified and it is determining if the received datagram is a token, and if it is a token and the token is valid, the datagram is forwarded to the downstream neighbor node on the virtual ring. Thereafter, it is determined if the received datagram is a virtual ring datagram. If the received datagram is not locally originated, it is forwarded to the downstream neighbor node, and if the received datagram is locally originated, it is removed from the virtual ring.
In another aspect of the invention, a computer network is provided with at least two nodes having transport layer protocol to provide end to end data transfer to multicast datagrams on a virtual ring. Each node on the ring is logically connected to an upstream neighbor node and a downstream neighbor node through a virtual connection. Instructions are provided to multicast datagrams on the virtual ring. The instructions include sending a virtual ring datagram to the downstream neighbor node on the virtual ring and identifying the received datagram. If the received datagram is a token and the token is valid, it is forward to the downstream neighbor node. Similarly, if the received datagram is a virtual ring datagram, it is forwarded to the downstream neighbor node if it has not been locally originated. However, if the received datagram has been locally originated, it is removed from the virtual ring.
In yet another aspect of the invention, an article is provided with a computer network having at least two nodes having a transport layer protocol to provide end to end data transfer to multicast datagrams in a virtual ring. Each node on the virtual ring is logically connected to an upstream neighbor node and a downstream neighbor node through a virtual connection. The article includes a computer readable medium in the network having instructions for multicasting datagrams on the virtual ring. The instructions include instructions for sending a virtual ring datagram to the downstream neighbor node, and instructions for identifying the datagram upon receipt. If the received datagram is a valid token, instructions are provided for forwarding the token to the downstream neighbor node. Similarly, instructions are provided for determining if the received datagram is a virtual ring datagram. Instructions are provided for forwarding the datagram to the downstream neighbor node if the received datagram has not been locally originated, and instructions are provided for removing the received datagram from the virtual ring if the received datagram has been locally originated.
The foregoing, together with other objects, features, and advantages of this invention can be better appreciated with reference to the following specification, claims and drawings.
The new and inventive features believed characteristics of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objects and advantages thereof, will best be understood by reference to the following detailed description of an illustrative detailed embodiment when read in conjunction with the accompanying drawings, wherein:
The present invention discloses a network topology based on a virtual ring as shown in
Although the present invention applies to any types of nodes, this invention is particularly interesting when several nodes need to exchange a same piece of information between them.
Several virtual rings can be implemented on a same physical network, each virtual ring allowing a subset of nodes to communicate together. A same node can participate to several virtual rings at the same time. Each virtual ring is identified by a unique Virtual Ring identifier, e.g. Virtual Ring Id. The Virtual Ring identifier is statically configured in all the nodes participating in the virtual ring. The way the virtual ring is initiated and managed will be described hereafter.
TCP/IP Protocol
In a preferred embodiment, the current invention is implemented on top of the TCP layer of the TCP/IP protocol, which is today the protocol the most largely used in the world. However, the invention only uses the transport function of TCP. It is also possible to implement the invention on top of any other protocol stack providing the transport function, such as IPX (Internetwork Packet Exchange). IP has been chosen in the present description because this protocol is used in most of the networks. The transport function of TCP brings some reliability because this function handles transmission problems such as packet losses. The circulation of information along the virtual ring is based on the Internet Protocol (IP) and the Transmission Control Protocol (TCP). TCP has been chosen because it allows a sending of packets without risk of loss. TCP also informs of the loss of the remote node by maintaining a connection. The use of TCP and IP allows to extend the virtual ring to any part of an IP network including the Internet itself. It is possible to imagine nodes in different parts of the world, communicating together with such a virtual ring.
The User Datagram Protocol (UDP) can also be used in the current invention for instance to exchange Ring Insertion and Ring Removal messages between a specific node and the Virtual Ring Manager. Since these messages are exchanged only during the insertion or removal process, there is no need to use the TCP protocol and to establish a TCP session.
The present invention requires a new specific piece of code in each node part of the ring network. This code uses a specific TCP port and a specific UDP port reserved for the invention. This code is used to establish, maintain and tear down the virtual ring topology
Token
In order to maintain the ring topology, some pieces of information need to be periodically exchanged between the different nodes. One of these pieces of information is called “token”, referring to the “Token Ring” architecture developed by IBM (IBM is a trademark of International Business Machines Corporation) these last decades.
The token is used as a periodic keepalive message to validate the ring topology. The token is periodically generated by the Virtual Ring Manager (402) and forwarded by each node to its downstream neighbour node. The receipt by the Virtual Ring Manager of the token (from its upstream neighbour node), indicates that the ring topology is valid and the loop is not broken. If the ring is broken for some reason, such as loss of one node or loss of connectivity between 2 neighbour nodes, the loss of the token will indicate that there is a problem on the ring. Each node monitors the reception of the token. If the token has not been received after a certain amount of time, each node will trigger the Ring Recovery process detailed here after. The token is forwarded from node to node, just like any other piece of information. This means that the Token uses the TCP sessions established between the nodes.
The Sequence Number field is used to identify the current copy of the token.
Token structure
IP Header
IP Header
Virtual Ring Token
Message Code 0x0001
Virtual Ring Identifier (2 bytes)
Sequence Number (4 bytes)
The Token is described in
When a node participating in the virtual ring receives a datagram from its upstream neighbour node, it processes this datagram, i.e. stores the data part of the received message, and forwards it to its downstream neighbour node so that the datagram can circulate along the virtual ring. However, a node connected to the virtual ring must be able to recognize a datagram circulating along the virtual ring versus a normal IP datagram received from another node which does not participate in the virtual ring. To do so, datagrams exchanged on the virtual ring have the following encapsulation:
IP Header
TCP Header
Virtual Ring Header
Data
(20 bytes)
Source/Dest Port
Message Code 0x0000
(20 bytes)
Virtual Ring Identifier (2 bytes)
Sender IP address (4 bytes)
The encapsulation of the Data inside a TCP datagram has the following advantage: the datagram is transmitted along the Virtual Ring using the reliable TCP protocol. The Virtual Ring Header comprises the following fields:
The virtual ring is a list of nodes connected to form a ring. No node has the complete view of the ring. This list of nodes participating in the ring is stored nowhere in the network. Each node comprises the following information (Node Ring Record)
Virtual Ring Identifier (2 bytes) (configured)
Upstream Neighbor IP address (4 bytes)
Downstream Neighbour IP address (4 bytes)
Virtual Ring Manager IP address (configured) (4 bytes)
Backup Virtual Ring Manager IP address (configured) (4 bytes)
Virtual Ring Manager
One of the nodes participating in the virtual ring plays the role of “Virtual Ring Manager”. The Virtual Ring Manager is responsible for maintaining the topology of the virtual ring, more particularly the Virtual Ring Manager is responsible for the insertion and removal of the nodes.
It is important to note that the Virtual Ring Manager IP address is statically configured in each node of the virtual ring. Since the Virtual Ring Manager constitutes a single point of failure, a Backup Virtual Ring Manager is generally used. The IP address of the Backup Virtual Ring Manager is also statically configured in each node. When a node wants to be inserted into the virtual ring and does not receive any response from the Virtual Ring Manager, this node will contact the Backup Virtual Ring Manager.
Insertion of a Node in the Virtual Ring
Note: in a preferred embodiment, all the insertion messages use the UDP protocol and the reserved UDP port defined in the current invention.
The solicited node removal scenario described in the present section corresponds to the case where a node wants to be removed from the Virtual Ring because it does not want to participate any more in the group. Another node removal scenario corresponds to the case where a node has a failure and the virtual ring is broken. This unsolicited removal scenario will be described in another section.
The loss of a node in the virtual ring network is detected by its neighbour nodes with the loss the TCP connections. When a node is removed from the virtual ring without informing the Virtual Ring Manager by means of a “Virtual Ring Removal Request” message, which should be the case when a node failure occurs, the 2 neighbour nodes, e.g. the upstream neighbour node and the downstream neighbour node, lose their TCP connection with this node a given period of time (after a TCP timeout). As described in
Backup Virtual Ring Manager
The Backup Virtual Ring Manager executes the same processes as the Virtual Ring Manager. The Backup Virtual Ring Manager receives Insertion, Removal and Recovery messages from the nodes in absence of response from the Virtual Ring Manager, and processes these messages like the Virtual Ring Manager.
Token Loss Recovery
All the nodes including the Virtual Ring Manager, use a timer to detect the loss of the token. When the token is lost, the ring needs to be rebuilt. The value of this timer must be larger than the TCP session timer to allow the process described in section entitled “Loss of a node” to take place before the reconfiguration of the ring. When a node detects the loss of the token, it sends a “Virtual Ring Removal Request” message to the Virtual Ring Manager and waits for the confirmation as described in
Insertion and Removal Messages
These messages are exchanged using the User Datagram Protocol (UDP). The value of the Virtual Ring Identifier field is used to identify the current virtual ring. The Virtual Ring Identifier is statically configured in each participating node.
General Format
IP Header
TCP Header
Virtual Ring Message
Source/Dest Port
Message Code 0x..
Virtual Ring Identifier (2 bytes)
. . .
Virtual Ring Insertion Request
Message Code
Virtual Ring
Inserting Node IP address
0x0002
Identifier (2 bytes)
(4 bytes)
Virtual Ring Insertion Confirmation
Message Code
Virtual Ring
Upstream
Downstream
0x0003
Identifier
Neighbour
Neighbour
(2 bytes)
IP address (4 bytes)
IP address (4 bytes)
Virtual Ring Change Neighbour
Message
Virtual Ring
Upstream Neighbour
Downstream
Code
Identifier
IP address (4 bytes)
Neighbour
0x0004
(2 bytes)
IP address (4 bytes)
Virtual Ring Neighbour Changed
Message
Virtual Ring
Upstream Neighbour
Downstream
Code
Identifier
IP address (4 bytes)
Neighbour IP address
0x0005
(2 bytes)
(4 bytes)
Virtual Ring Removal Request
Message
Virtual Ring
Removing
Upstream
Downstream
Code
Identifier
Node IP
Neighbour IP
Neighbour IP
0x0006
(2 bytes)
address
address
address
(4 bytes)
(4 bytes)
(4 bytes)
Virtual Ring Removal Confirmation
Message Code
Virtual Ring
0x0007
Identifier
(2 bytes)
Virtual Ring Neighbour Loss Indication
Message
Virtual Ring
Upstream
Downstream
Node IP
Code 0x0008
Identifier
Neighbour IP
Neighbour IP
address
(2 bytes)
address
address
(4 bytes)
(4 bytes)
(4 bytes)
Processes According to the Present Invention
Token Processing in a Node
In one embodiment, the invention is implemented in software and can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain or store the program for use by or in connection with the instruction execution system, apparatus, or device. In one embodiment, the computer program is executed on a node in the network.
With the present invention, only N TCP sessions are required to interconnect N nodes versus N×(N−1)/2 sessions in a full meshed network or 2×N−3 sessions in a dual star configuration. A session is a virtual connection between two nodes, enabling the exchange of data between these nodes and taking care of transmission problems like flow control and retransmission. A TCP session is an example of session between two nodes supporting the TCP/IP protocol. The current invention is implemented on top of the TCP (Transmission Control Protocol) layer of the TCP/IP protocol stack, and can be used by any node supported by the TCP/IP protocol, which is the protocol the most widely used in the world. As illustrated in
According to the present invention, each node has to establish a TCP session with only 2 other nodes: the upstream neighbour node and the downstream neighbour node. This means a total of N sessions in a virtual ring of N nodes. The saving resulting from the present invention can be calculated as follows:
N×(N−1)/2 sessions in a full meshed network versus N sessions in the virtual ring configuration. The difference is equal to N×(N−1)/2−N=N2/2−N/2−N=N2/2−3N/2=N×(N−3)/2.
Therefore, the current invention allows to save N×(N−3)/2 sessions in the network.
Reducing the number of sessions between the nodes brings several other advantages as it will be explained in the following points.
The present invention avoids multiple and unnecessary copies because each node receives one and only one copy of a same message. In a full meshed topology as described in
The present invention enables the exchange of a same piece of information between all the nodes so that each node receives one and only one copy of the information. Because nodes are virtually connected to a virtual ring, and because the information circulates along that ring and is seen by each node connected to the ring, the network is not flooded by multiple copies of messages exchanged between nodes.
Establishing and Maintaining a TCP session requires computer resources to manage the flow control, the retransmission, and to generate acknowledgements and keepalives. The present invention reduces the number of TCP sessions required for nodes to communicate, and therefore reduces the utilization of data processing resources in nodes.
In each node, the maintenance of TCP sessions requires to keep the context of these session, with information such as the sequence number of the last segment sent, or the sequence number of the next acknowledgement to send. The storage of this information consumes memory. Reducing the number of TCP sessions has resulted in reducing the memory consumption in the nodes.
While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood that various changes in form and detail may be made therein without departing from the spirit, and scope of the invention.
Sicsic, Patrick, Esteve, Denis, Denecheau, Lionel
| Patent | Priority | Assignee | Title |
| 8014406, | Oct 03 2006 | International Business Machines Corporation | System and method of inserting a node into a virtual ring |
| 8090256, | Oct 04 2006 | Arizona Board of Regents, a Body Corporate of the State of Arizona, Acting for and on Behalf of Arizona State University | Optical network architectures and optical communication schemes |
| 8295700, | May 14 2007 | Intune Technologies | Distributed packet switch for use in a network |
| 9160453, | Sep 29 2010 | Fujitsu Limited | Ring network setup method |
| 9331861, | Dec 17 2010 | TELEFONAKTIEBOLAGET L M ERICSSON PUBL | Ethernet ring node with improved recovery time after a link failure |
| 9699021, | Nov 21 2011 | TELEFONAKTIEBOLAGET L M ERICSSON PUBL | Ring protection state aware bandwidth adaptation |
| Patent | Priority | Assignee | Title |
| 4538147, | Mar 05 1982 | Unisys Corporation | Bandwidth allocation in a token controlled loop communications network |
| 4590468, | Mar 10 1983 | STANDARD MICROSYSTEMS CORPORATION A CORPORATION OF DE | Token access controller protocol and architecture |
| 4713807, | May 24 1985 | Nortel Networks Limited | Intelligence transmission system of the local area network type |
| 4731784, | Feb 28 1985 | International Business Machines Corp. | Communication system comprising overlayed multiple-access transmission networks |
| 4736368, | Dec 16 1985 | Texas Instruments Incorporated | Priority token protocol circuit for a token ring local area network adaptor |
| 4766530, | Nov 24 1986 | Westinghouse Electric Corp. | Token passing scheme for a predetermined configuration local area network |
| 4780871, | Jul 09 1985 | Canon Kabushiki Kaisha | Data Transmission system |
| 4860284, | Apr 20 1988 | American Telephone and Telegraph Company, AT&T Bell Laboratories | Method and apparatus for identifying location of a lost token signal in a data communication network |
| 5023871, | Apr 28 1988 | Hitachi, Ltd. | Method of controlling the operation of stations in a ring network |
| 5053946, | May 26 1988 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Token ring network having token request mechanism |
| 5107490, | Apr 24 1985 | 3 Com Corporation | Ring-type communication network |
| 5243596, | Mar 18 1992 | Round Rock Research, LLC | Network architecture suitable for multicasting and resource locking |
| 5253252, | Jan 10 1989 | Invensys Systems, Inc | Token device for distributed time scheduling in a data processing system |
| 5289390, | May 22 1992 | Agilent Technologies Inc | Method for determining the electrical cable length of an active ring of a token ring local area network |
| 5383186, | May 04 1993 | The Regents of the University of Michigan | Apparatus and method for synchronous traffic bandwidth on a token ring network |
| 5490145, | May 25 1993 | Matsushita Electric Industrial Company, Ltd. | Communication system for a ring-type network |
| 5553073, | May 17 1993 | IBM Corporation | Token ring network |
| 5604742, | May 31 1995 | International Business Machines Corporation | Communications system and method for efficient management of bandwidth in a FDDI station |
| 5752003, | Jul 14 1995 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Architecture for managing traffic in a virtual LAN environment |
| 5802056, | Jul 12 1996 | RPX CLEARINGHOUSE LLC | Configuration of virtual rings in a token ring local area network |
| 5802060, | Dec 23 1994 | Koninklijke Philips Electronics N V | Data network and a process for real time transmission of data packets in a data network |
| 5886992, | Apr 14 1995 | Intellectual Ventures Holding 9 LLC | Frame synchronized ring system and method |
| 6005869, | Apr 17 1996 | Matsushita Electric Industrial Co., Ltd. | Communication network |
| 6154462, | Aug 21 1997 | CommScope EMEA Limited; CommScope Technologies LLC | Circuits and methods for a ring network |
| 6366556, | Jun 22 1998 | Lucent Technologies Inc. | Self-healing networks using virtual rings |
| 6393489, | Feb 11 1997 | SECURE AXCESS LLC | Media access control architectures and network management systems |
| 6460101, | Nov 09 1999 | International Business Machines Corporation | Token manager for execution of global operations utilizing multiple tokens |
| 6563833, | Jan 05 1999 | WSOU Investments, LLC | Combinatorial design method and apparatus for multi-ring networks with combined routing and flow control |
| 6639893, | Mar 30 1998 | Kabushiki Kaisha Toshiba | Communication network system including ring network that performs communication through multiple switching devices |
| 6880017, | Mar 20 2000 | International Business Machines Corporation | System and method for providing an adaptive streaming flow control mechanism between the TCP and IP layers of the TCP/IP suite of protocols |
| 7106695, | May 29 2001 | International Business Machines Corporation | Method of allocating bandwidth to the stations of a local area network |
| 7181547, | Jun 28 2001 | Fortinet, INC | Identifying nodes in a ring network |
| 7269731, | Jan 29 2003 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Message authorization system and method |
| 7287170, | May 14 2002 | ATI Technologies ULC | Method and apparatus for power management using system and request tokens |
| 7366109, | Oct 29 2003 | CIENA LUXEMBOURG S A R L ; Ciena Corporation | Virtual private networks within a packet network having a mesh topology |
| 20020112065, | |||
| 20020181505, | |||
| 20030035436, | |||
| 20030041164, | |||
| 20030154285, | |||
| 20070268913, | |||
| EP561381, | |||
| WO9909713, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Nov 30 2004 | International Business Machines Corporation | (assignment on the face of the patent) | / | |||
| Aug 08 2006 | DENECHEAU, LIONEL | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018701 | /0141 | |
| Aug 08 2006 | ESTEVE, DENIS | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018701 | /0141 | |
| Aug 08 2006 | SICSIC, PATRICK | International Business Machines Corporation | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 018701 | /0141 |
| Date | Maintenance Fee Events |
| May 19 2010 | ASPN: Payor Number Assigned. |
| Jan 17 2014 | REM: Maintenance Fee Reminder Mailed. |
| Apr 11 2014 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
| Apr 11 2014 | M1554: Surcharge for Late Payment, Large Entity. |
| Jan 22 2018 | REM: Maintenance Fee Reminder Mailed. |
| Jul 09 2018 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
| Date | Maintenance Schedule |
| Jun 08 2013 | 4 years fee payment window open |
| Dec 08 2013 | 6 months grace period start (w surcharge) |
| Jun 08 2014 | patent expiry (for year 4) |
| Jun 08 2016 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jun 08 2017 | 8 years fee payment window open |
| Dec 08 2017 | 6 months grace period start (w surcharge) |
| Jun 08 2018 | patent expiry (for year 8) |
| Jun 08 2020 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jun 08 2021 | 12 years fee payment window open |
| Dec 08 2021 | 6 months grace period start (w surcharge) |
| Jun 08 2022 | patent expiry (for year 12) |
| Jun 08 2024 | 2 years to revive unintentionally abandoned end. (for year 12) |