Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
2000-01-31
2004-10-19
Hsu, Alpus H. (Department: 2665)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S463000, C709S250000
Reexamination Certificate
active
06807182
ABSTRACT:
FIELD OF THE INVENTION
This invention relates generally to packet-based communication systems, such as ‘Ethernet’ systems, wherein data is conveyed by means of data packets that include address data and control or type data in addition to, in general, message data and cyclic redundancy code data.
The invention more particularly relates to network devices which can be stacked so as effectively to form a single logical unit and more particularly relates to a stack which can accommodate a trunk which has physical ports on a multiplicity of stacked units which include protocol engines.
BACKGROUND OF THE INVENTION
It is known to extend the performance or versatility of a network device, such as a switch, repeater or router for example by forming a stack of similar units. Each device normally is a multi-port device which can forward packets from or receive packets at any of the ports (which can typically both forward and receive packets) and it is known to connect such stack units by means of a cascade connection whereby for example a packet received at a port on one of the units in the stack can be directed to a port on another stack. Since units of this nature maintain a database which identify the remote devices which are connected to the respective ports, a packet received at a port on a particular unit and intended for a second remote device to which no port on that unit is connected can be tagged so that the packet is conveyed by way of a cascade connection to the other units including the one to which the second remote device is connected.
In general practice hitherto, each remote device to which a unit in a stack is connected is connected to a single one of the ports. However, in more recent practice the expedient of a trunked port has been developed. A trunked port is in essence a multi-path connection from a remote device to a multiplicity of ports. The advantage of a trunked port or trunk is that it can carry much more traffic than a single connection and accordingly it is useful where the data packet traffic from (or to) a particular device, such a server, is likely to be very heavy, so that it would likely exceed the traffic carrying capacity of a single link to a single port on a switch or other device.
Where a trunk is connected to a multiplicity of physical ports on a single device or unit, it is known practice to employ, for forwarding packets to the trunk, a ‘logical’ or ‘bridge’ port and for the unit to direct all packets intended for forwarding over the trunk to that logical internal port. By means of hashing address data of the packet, the packets are distributed to the physical ports connected to the trunk. Packets received over the trunk will in any event be directed from the physical ports to the internal ‘logical’ or ‘bridge’ port.
Prior copending applications Ser. Nos. 09/201,368 and 09/201,345 to Jennings et al., filed 30 Nov. 1998, now issued as U.S. Pat. Nos. 6,463,479 and 6,425,015, respectively, describe the distribution of ports of a trunk over a plurality of units in a stack. It is necessary to be able to distinguish at a cascade port between packets that come via the cascade from another unit connected to a source which has a trunk connection to physical ports on both units and packets from a different source connected to merely another unit but which must arrive at the first unit by way of the cascade. This is solved according to the aforementioned applications by tagging packets (i.e. inserting a tag field) when they are transmitted by a cascade link to indicate whether the packet in question has arrived at the stack on a port which forms part of a trunk connection and, if so, which trunk. Such a field may be inserted immediately in front of a destination address field in a packet or at any other appropriate or convenient position within the data packet.
The present invention concerns the running of protocol engines on a unit which forms part of a stack and wherein there is a trunk connection to a multiplicity of physical ports on two or more of the units in the stack.
A protocol engine is an entity, normally modeled as a finite state machine, that takes in data formatted according to the protocol formatting rules and produces a deterministic output based on that incoming data, previous data inputs and the processing rules of the protocol. That output is then applied to the system outside the protocol engine. The output could be in the form of some protocol data that is to be transmitted or some command passed to the external system.
In traditional systems a protocol engine is run on each unit in the stack. Each protocol engine controls all of the ports on the unit it is running on. With a trunk port that has physical ports on multiple units this solution does not work. Firstly the internal inputs to the protocol engine come, in part, from the packets that are received for that port. With a distributed trunk these protocol packets would be received by the local protocol engines which would not have knowledge of the packets received by other protocol engines. Since a protocol engine uses current and previous inputs to determine its current output, receiving an incomplete set of inputs would prevent the protocol engine from functioning correctly.
Secondly, the output from the protocol engines must be applied coherently to the trunk port. That is to say that any output packets should not be sent multiple times. It is not sufficient for the state of the port to simply be the state set by the last protocol engine that affected the port. Additionally any state applied to the trunk port must be applied to all physical ports that are a member of that trunk port and not just to the physical ports on any particular unit.
Hitherto, protocol engines which have been run on distributed systems, that is to say a system of stacked units, have required the running of a respective protocol engine on each unit in the stack and to arrange for the protocol engines to communicate across the stack to maintain synchronization within the stack. This solution is satisfactory for port-based system in the absence of a trunk which has physical ports distributed over the units in the stack, because all the data that a protocol engine requires is available locally on the unit to which the trunk ports are connected.
If a trunk (or each trunk) is connected to physical ports on more than one unit in a stack, some of the information that a protocol engine working with a trunk needs is now held on a remote unit in the stack.
As the remote sender is entitled to send protocol data messages down any of the physical ports in the trunk there is no guarantee which physical port and therefore which unit will receive any protocol messages sent. Protocol messages sent to special addresses reserved for that protocol will not automatically be forwarded across the cascade in the way that normal data packet would be. This means that unsolicited protocol messages and replies that use special addresses could arrive at any unit in the stack.
To enable protocol engines to use distributed trunked ports some mechanism must be found to make the information for that trunk port available locally to the protocol engine. Since the protocol packets that are needed by the protocol engine can only be identified by looking at the destination MAC address, packet type, incoming port number, and, in some cases, by looking into the data contents of the packet, the normal MAC address based forwarding mechanism will not solve this problem.
If a trunk is connected to ports on a multiplicity of units then the trunk can potentially be controlled by a multiplicity of protocol engines. In the majority of cases a single protocol engine should be running on the trunk port.
SUMMARY OF THE INVENTION
The present invention is based on a scheme wherein the trunk is unified into a single logical port located somewhere in the stack from the point of view of all the protocol engines within the stack. Thus the protocol engines are all presented with a single extra port on one unit in the stack. Actions that are applied to the logi
Dolphin Clive
Goodfellow Maurice
McKerrell Graeme J
Moran Paul J
3Com Corporation
Hsu Alpus H.
Nixon & Vanderhye PC
LandOfFree
Stacked network devices including a protocol engine and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Stacked network devices including a protocol engine and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Stacked network devices including a protocol engine and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3312020