Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1999-08-06
2004-08-31
Nguyen, Steven (Department: 2665)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S390000, C370S229000
Reexamination Certificate
active
06785286
ABSTRACT:
FIELD OF THE INVENTION
The invention relates to the control of the operation of multi-port communication devices intended for in packet-based data communication systems such as the Ethernet. More particularly it relates to the inhibition of duplication of packet flow when port mirroring is provided for a stack of multi-port communication devices coupled by a trunked cascade.
BACKGROUND TO THE INVENTION
It is convenient to connect multi-port communication device such as repeaters, bridges, switches and the like so that externally they appear as a single logical entity. As a practical matter devices are made with a limited number of ports and the connection of a multiplicity of units together in a cascade, wherein each of the units has at least one port connected to a port of each other unit in the stack, provides a convenient way of producing a device with a greater number of ports. However, the provision of a cascade connection makes certain network functions more complex, as is exemplified below.
An important technique in network management is known as ‘port mirroring’, which is a desirable feature for any multi-port communication device. The ability of a device to support mirroring means that it can copy all data packets sent or received on one particular port to another port. The device needs to be configured to determine which port should be a ‘study’ port and which port is to be the ‘copy’ port to which a copy of all packets seen on the study port are sent The copy port is also known as the ‘roving analysis port’ (RAP port)
Trunking is another desirable feature for multi-port communication devices. Devices which are connected together by a single physical link may suffer from insufficiency of bandwidth or information capacity owing to the volume of traffic flowing between the two devices. Trunking of ports helps alleviate this problem because it allows physical ports to be grouped together so that they appear as a single logical port. Once the trunk has been created, it is represented internally in the switch by a single port number known as the ‘master’ or ‘bridge’ port. Packets which are destined for a remote device that is linked via a trunk are directed to the bridge port of that trunk and simple low level circuitry decides, for example by means of hashing algorithm, which physical port of the trunk should be used for forwarding the packet to the remote device.
The roving analysis port operates at a physical port level in that the RAP port identifies a single physical port rather than a logical port. The RAP logic operates at a physical port level so that it can ‘study’ physical ports as opposed to logical ports. To allow this logic to study at the physical layer provides the ability to study an individual port of a trunk. To study at the logical level would permit the study of the single logical port that represents the trunk and all the traffic of the trunk would be studied. To study a physical port of a trunk is more desirable because this feature can be used to debug an operational fault in relation to a particular port.
This creates a problem if port mirroring is to be supported across a stack of units that are linked together by a trunked cascade. If a packet which is to be forwarded down the cascade is also to be sent to the RAP port then there is a danger of packet duplication.
If the RAP port is not on the same device, then the cascade must be identified as the RAP port on this unit, as the cascade will take a packet to the unit that actually contains the RAP port. The cascade port chosen to identify the RAP port would be one of the physical ports of the trunked cascade. In this example, let the RAP port be identified as the logical port (bridge port) of the trunk Since the cascade trunking logic is at the logical level, the packet will pass through it before it goes to the physical layer's RMON logic. If the switching logic sends the packet to the cascade, then it will be directed to the logical port of the cascade. The hashing algorithm will then either allow the packet to go out this logical port or will redirect it to the other physical port of the Trunk. In the former case, the port mask that is sent to the RAP logic will have the corresponding bit for the logical port set If the RAP logic decides to study the packet and hence send the packet to the RAP port, it will see by means of the port mask that the packet is already going to the RAP port and so does not need to forward the packet to the RAP port itself. The RAP port in this unit was previously defined as the logical port of the cascade trunk. Accordingly, if the hashing algorithm selects the other physical port of the cascade, the mask that is sent to the RAP logic will have this bit set and not the bit of the logical port of the cascade. When the RAP logic decides to study a packet and send it to the RAP port, it will check if the bit for the RAP port is set in the mask (in this case it will not be set) and so will send the packet to the RAP port (logical port of the cascade). Now the bits for the logical port of the cascade and the other physical port of the cascade are set in the port mask and so the packet is sent down the cascade twice.
A second difficulty arises for units in a stack that do not contain the roving analysis port. These other units are configured to identify the RAP port as one of the physical ports of the cascade as this port will take a packet to the unit that actually contains the RAP port. Any packet which it receives and which are tagged for RMON analysis will be sent out of its designated RAP unless it received those packets on its RAP port. When the cascade is trunked it may receive a tagged packet on a different cascade port to its RAP port and so will attempt to forward the packet out on to the cascade again.
SUMMARY OF THE INVENTION
The present invention is particularly intended to avoid duplication of packets in the circumstances indicated in the foregoing and similar circumstances, i.e. to permit the mirroring of a port on one unit of a stack with a port on another unit when those units are connected by a trunked cascade, namely a manifold connection in which two or more ports of one unit are each connected to a respective port of the other unit, by preventing the dispatch down the cascade of both a packet and a copy. This is achieved by employing a mask register to detect whether a packet has already been sent down one of the cascade ports or has been received from a cascade trunk port.
The invention will be more particularly explained with reference to the accompanying drawings.
REFERENCES:
patent: 5909438 (1999-06-01), Melden et al.
patent: 6016310 (2000-01-01), Muller et al.
patent: 6141355 (2000-10-01), Palmer et al.
patent: 6304690 (2001-10-01), Day
patent: 6430180 (2002-08-01), Bohm et al.
patent: 0841832 (1998-05-01), None
patent: 2330741 (1999-04-01), None
patent: 2333428 (1999-07-01), None
patent: 2333429 (1999-07-01), None
patent: 2334863 (1999-09-01), None
patent: WO 95/03659 (1995-02-01), None
Clifford Neil J
Law David J
Moran Paul J
O'Keeffe Daniel M
3Com Corporation
Nguyen Steven
Nixon & Vanderhye PC
Tran Thien
LandOfFree
Port mirroring across a trunked stack of multi-port... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Port mirroring across a trunked stack of multi-port..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Port mirroring across a trunked stack of multi-port... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3355573