|Publication number||US20050041684 A1|
|Application number||US 10/900,793|
|Publication date||Feb 24, 2005|
|Filing date||Jul 27, 2004|
|Priority date||Oct 1, 1999|
|Also published as||US6925052|
|Publication number||10900793, 900793, US 2005/0041684 A1, US 2005/041684 A1, US 20050041684 A1, US 20050041684A1, US 2005041684 A1, US 2005041684A1, US-A1-20050041684, US-A1-2005041684, US2005/0041684A1, US2005/041684A1, US20050041684 A1, US20050041684A1, US2005041684 A1, US2005041684A1|
|Inventors||Alastair Reynolds, Douglas Carson, George Lunn, William MacIsaac|
|Original Assignee||Agilent Technologies, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (19), Referenced by (66), Classifications (9), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The invention relates to telecommunications networks, and in particular to apparatus and systems for monitoring traffic in broadband networks.
In telecommunication networks, network element connectivity can be achieved using optical fibre bearers to carry data and voice traffic.
Data traffic on public telecommunication networks is expected to exceed voice traffic with Internet Protocol (IP) emerging as one data networking standard, in conjunction with Asynchronous Transfer Mode (ATM) systems. Voice over IP is also becoming an important application for many Internet service providers with IP switches connecting IP networks to the public telephony network (PSTN). IP can be carried over a Sonet transport layer, either with or without ATM. In order to inter-operate with the PSTN, IP switches are also capable of inter-working with SS7, the common signalling system for telecommunications networks, as defined by the International Telecommunications Union (ITU) standard for the exchange of signalling messages over a common signalling network.
Different protocols are used to set up calls according to network type and supported services. The signalling traffic carries messages to set up calls between the necessary network nodes. In response to the SS7 messages, an appropriate link through the transport network is established, to carry the actual data and voice traffic (the payload data) for the duration of each call,. Traditional SS7 links are time division multiplexed, so that the same physical bearer may be carrying the signalling and the payload data. The SS7 network is effectively an example of an “out of band” signalling network, because the signalling is readily separated from the payload. For ATM and IP networks, however, the signalling and payload data is statistically multiplexed on the same bearer. In the case of statistical multiplexing the receiver has to examine each message/cell to decide if it is carrying signalling or payload data. One protocol similar to SS7 used in such IP networks is known as Gateway Control Protocol (GCP).
The monitoring of networks and their traffic is a fundamental requirement of any system. The “health” of the network must be monitored, to predict, detect and even anticipate failures, overloads and so forth. Monitoring is also crucial to billing of usage charges, both to end users and between service providers. The reliability (percentage availability) of monitoring equipment is a prime concern for service providers and users, and many applications such as billing require “high availability” monitoring systems, such that outages, due to breakdown or maintenance, must be made extremely rare.
A widely-used monitoring system for SS7 signalling networks is acceSS7 ™ from Agilent Technologies (and previously from Hewlett-Packard). An instrument extracts all the SS7 packetised signals at Signalling Transfer Points (STPs), which are packet switches analogous to IP routers, that route messages between end points in SS7 networks. The need can be seen for similar monitoring systems able to cope with combined IP/PSTN networks, especially at gateways where the two protocols meet. A problem arises, however, in the quantity of data that needs to be processed for the monitoring of IP traffic. In Internet Protocol networks, there is no out of band signalling network separate from the data traffic itself. Rather, routing information is embedded in the packet headers of the data transport network itself, and the full data stream has to be processed by the monitoring equipment to extract the necessary information as to network health, billing etc. Moreover, IP communication is not based on allocating each “call” with a link of fixed bandwidth for the duration of the call: rather bandwidth is allocated by packets on demand, in a link shared with any number of other data streams.
Accordingly, there is a need for a new kind of monitoring equipment capable of grabbing the vast volume of data flowing in the IP network bearers, and of processing it fast enough to extract and analyse the routing and other information crucial to the monitoring function. The requirements of extreme reliability mentioned above apply equally in the new environment.
Networks such as these may be monitored using instruments (generally referred to as probes) by making a passive optical connection to the optical fibre bearer using an optical splitter. However, this approach cannot be considered without due attention to the optical power budget of the bearer, as the optical splitters are lossy devices. In addition to this, it may be desirable to monitor the same bearer many times or to monitor the same bearer twice as part of a backup strategy for redundancy purposes. With available instrumentation, this implies a multiplication of the losses, and also disruption to the bearers as each new splitter is installed. Issues of upgrading the transmitter and/or receiver arise as losses mount up.
The inventors have analysed acceSS7 network monitoring systems (unpublished at the present filing date). This shows that the reasons for lack of availability of the system can be broken down into three broad categories: unplanned outages, such as software defects; planned outages, such as software and hardware upgrades; and hardware failures. Further analysis shows that the majority of operational hours lost are caused by planned and unplanned maintenance, while hardware failures have a relatively minor effect. increasing the redundancy of disk drives, power supplies and the like, although psychologically comforting, can do relatively little to improve system availability. The greatest scope for reducing operational hours lost and hence increasing availability is in the category of planned outages.
In order to implement a reliable monitoring system it would therefore be advantageous to have an architecture with redundancy allowing for spare probe units that is tolerant of both probe failure and probe reconfiguration, and provides software redundancy.
Monitoring equipment designed for this purpose does not currently exist. Service providers may therefore use stand-alone protocol analysers which are tools really intended for the network commissioning stage. These usually terminate the fibre bearer, in place of the product being installed, or they plug into a specific test port on the product under test. Specific test software is then needed for each product. Manufacturers have alternatively built diagnostic capability into the network equipment itself, but each perceives the problems differently, leading to a lack of uniformity, and actual monitoring problems, as opposed to perceived problems, may not be addressed.
Further considerations include the physical environment needed to house such processing architecture. Such a hardware platform should be as flexible as possible to allow for changes in telecommunications technology and utilise standard building blocks to ensure cross platform compatibility. For example, there exist standards in the USA, as set out by the American National Standards Institute (ANSI) and Bellcore, which differ from those of Europe as set by the European Telecommunications Standards Institute (ETSI). Versions of SS7 may also vary from country to country, owing to the flexibility of the standard, although the ITU standard is generally used at international gateways. The USA Bellcore Network Equipment-Building System (NEBS) is of particular relevance to rack-mounted telecommunications equipment as it provides design standards for engineering construction and should be taken into account when designing network monitoring equipment. Such standards impose limitations such as connectivity and physical dimensions upon equipment and, consequently, on cooling requirements and aisle spacing of network rack equipment.
It is known that standard processing modules conforming for example to the cPCI standard are suitable for use in telecommunication applications. The further standard H.110 provides a bus for multiplexing baseband telephony signals in the same backplane as the cPCI bus. Even with Intel Pentium™ or similar processors, however, such arrangements do not currently accommodate the computing power needed for the capture and analysis of broadband packet data. Examples of protocols and their data rates to be accommodated in the monitored bearers in the future equipment are for example DS3 (44 Mbit.s−1), OC3 (155 Mbit.s−1), OC12 (622 Mbit.s−1) and OC48 (2.4 Gbit.s−1). Aside from the volume of data to be handled, conventional chassis for housing such modules do not also support probe architectures of the type currently desired, both in terms of processing capability and also to the extent that their dimensions do not suit the layout of telecommunication equipment rooms such as may be designed to NEBS allowing them to co-reside with network equipment.
For example, the typical general purpose chassis provides a rack-mounted enclosure in which a backplane supports and interconnects a number of cPCI cards, including a processor card and peripheral cards, to form a functional system. The cards are generally oriented vertically, with power supply (PSU) modules located above or below. Fans force air through the enclosure from bottom to top for cooling the modules. A peripheral card may have input and output (I/O) connections on its front panel. Alternatively, I/O connections may be arranged at the rear of the enclosure, using a special “transition card”. Examples of rack widths in common use are 19 inch (483 mm) and 23 inch (584 mm). The siting of racks in telecommunications equipment rooms implies an enclosure depth should be little over 12 inches (305 mm). However, cPCI and VME standard processor cards and compatible peripheral cards are already 205 mm deep (including mountings) and the conventional interface card mounted behind the back plane adds another 130 mm. Moreover, although parts of the connector pin-outs for cPCI products are standardised, different vendors use other connectors differently for management bus signals and for LAN connections. These variations must also be adapted to by dedicated interconnect, and designs will often assume that cards from a single vendor only are used.
In a first aspect the invention provides a rack-mountable enclosure comprising a housing and interconnection backplane for the mounting and interconnection of a plurality of card-shaped processing modules and at least one interface module, the interface module being arranged to provide a plurality of external connectors and to transport signals via the backplane between each external connection and an individual processing module, wherein:
This arrangement allows a compact housing to contain several processing modules and to receive a corresponding number of external connections, in a more compact and functionally dense manner than known instrument chassis designs. In particular, the location of the power supply module behind the backplane saves height and/or width in the rack.
It will be understood that “front” and “rear” are used for convenience, and their meanings can be reversed. One particular benefit of the specified arrangement is that all external connectors (and hence the associated cabling) can be located on one side of the enclosure, allowing consistent access for all cables at the rear in the crowded equipment rooms common to telecommunication and other installations. Using cPCI standard processor and peripheral cards, the depth of the enclosure can be kept within or close to 12 inches (305 mm), no greater than the surrounding telecommunication equipment.
The enclosure may be constructed so that the processor modules lie generally horizontally when the enclosure is rack mounted. Air paths may be defined through the enclosure so as to pass from end to end thereof, along and between the processor modules and, if necessary, the power supply and interface modules. Fans may be included, optionally in a redundant configuration, to ensure adequate air flow to cool the various components of the enclosure.
The external connectors may provide inputs, outputs or both. In a telecommunications network probe application, the transport of data in the backplane will generally be inward, from the external connectors to the processing modules. In particular, external input connectors may be provided by the interface module for broadband telecommunications signals, with high bandwidth interconnections provided in the backplane. In principle, the backplane could include optical interconnects. With present technology, however, any necessary optical to electrical conversion will more likely be included in the interface module. In other applications, for example process control or computer telephony, the transport may be in both directions, or outwards only. The transport via the backplane may be in essentially the same format in which it arrives. Alternatively, the interface module may change the format, for example to multiplex several of the external signals onto a single pair of conductors in the backplane. The enclosure and modules will find particular application wherever a large quantity of data needs to be processed at speed, and reduced by filtering and aggregation to provide information for use elsewhere.
For flexibility and particularly for redundancy in fault and maintenance situations, the enclosure may provide a location for at least one switching module, whereby routing of signals between the external connectors and individual processing modules can be varied. The switching module may in particular comprise a cross-point switch, in accordance with another aspect of the invention, set forth in more detail elsewhere. It is assumed in that case that the processing modules are “hot-swappable”, so that operation of other modules is unaffected by module replacement. The switching module may be operable to route signals between one external connector and a plurality of processing modules. This allows increased processing capacity to be provided for each external connector, whether this is used for redundancy or merely to add processing functionality.
For additional redundancy in larger systems, the switching module and interface module may provide for re-routing one of said signals from an external input connector to an additional output connector, to allow processing in another enclosure. The number of external input connectors may exceed the capacity of processing modules that can be accommodated, or may match it.
The backplane may separately provide local bus interconnections for communication between the processing modules. Said local bus interconnections may include a processor-peripheral parallel bus, for example cPCI. The processing module locations may be subdivided into groups, each group receiving a set of separately pluggable modules which together co-operate for processing of a given external signal. The backplane may in particular provide a plurality of independent local buses, each for communication between the modules of one group. The groups may each include a first processor module having specific capability for a type of input signal (such as IP packet data) to be analysed, and a second processor module of generic type for receiving partially processed data from the first processor module, and for further processing and reducing said data for onward communication.
The first and second processing modules can be regarded as packet and probe processor modules respectively, each such pair forming a self-contained probe unit. It will be understood that each probe processor card may be served by more than one packet processor card, and references to pairs should not be construed as excluding the presence of a further packet processor module in any group.
In the specific embodiments disclosed herein, two separate interface modules are provided at the rear side of the backplane. A first interface module, being the one referred to above, is for the signals to be processed (which broadly could mean input signals to be analysed or output signals being generated). A second interface module is provided for communication for control and management purposes, such as the onward communication of the processing results via LAN. These modules could of course be combined in one physical module, or further sub-divided, according to design requirements.
The external outputs may be connections to a computer Local Area Network (LAN), which can also provide for remote control and configuration of the processing modules. For redundancy of operation, the LAN connections in the backplane can be unique to each module, and can further be duplicated for each module. Alternatively, all modules can communicate via a common LAN. The backplane may provide a dedicated location for a management module for selective routing of the LAN or other output communications from the external connectors to the processing modules.
The backplane may further provide a communication bus connecting all modules, for management functions including for example power and cooling management. Said interconnections may for example include an I2C or SMB bus carrying standard protocols. For improved redundancy, separate buses may be provided for each sub-system.
Combining the above features, according to a particular embodiment of the invention in its first aspect, the backplane may provide:
The enclosure and backplane may further provide a location for a communication and management module to provide one or more of the following functions:
Alternatively, the first aspect of the invention provides a rack-mountable enclosure comprising a housing, a power supply module, a fan assembly and an interconnection backplane for the mounting and interconnection of a plurality of card-shaped processing modules, wherein the processing modules in use are arranged to lie generally horizontally in front of the backplane and generally parallel with one another, the power supply module is located behind the backplane, and the fan assembly is located to left or right of the processing modules (in use, as viewed from the front) so as to provide a generally horizontal airflow between them.
A shared interface module or modules for providing external connections to the backplane and hence to all of the processing modules may also be located behind the backplane.
It is noted at this point that the cPCI standard defines a number of physical connectors to be present on the backplane, but only two of these (J1, J2) are specified as to their pin functions. Although the second processing modules mentioned above are generic processor cards based for example on Pentium (™ of Intel Corp.) microprocessors, different card vendors use the remaining connectors differently for communication and management signals such as SMB and LAN connections.
According to a second aspect of the invention a multi-processor equipment enclosure provides a housing and a backplane providing locations for a plurality of processing modules, and further providing a plurality of locations for a configuration module corresponding to respective processing module locations, each configuration module adapting the routing of communication and management signals via the backplane, in accordance with the vendor-specific implementation of the processing module.
The configuration module locations may be on the backplane, or on another card connected to the backplane. In the preferred embodiment, a communication and management module is provided at a specific location, and the configuration module locations are provided on the management module.
In an alternative solution according to the second aspect of the invention, a multi-processor equipment enclosure provides a housing and a backplane providing interconnect for a plurality of processing modules and a management module, the backplane interconnect including generic portions standardised over a range of processing modules and other portions specific to different processing modules within said range, wherein said management module is arranged to sense automatically the specific type of processing module using protocols implemented by the modules via connections in the generic portion of the interconnect, and to route communication and management signals via the backplane, in accordance with the specific implementation of each processing module.
The type sensing protocols may for example be implemented via geographic address lines in the standardised portion of a compact PCI backplane.
It is noted that known chassis designs and backplanes do not provide for several channels of signals to be monitored by independent processing sub-systems within the same chassis, especially when each monitoring unit processor in fact requires more than one card slot for its implementation. In particular, for monitoring of broadband communication signals in IP or similar protocols, it is presently necessary to provide a first processing module dedicated to a first stage of data acquisition and processing, where the sheer quantity of broadband data would defeat a general-purpose processor card, and a second processing module of generic type, for further processing onward reporting of the data processed by the first processing module.
According to a third aspect of the invention a computer equipment chassis provides a housing and backplane providing locations for at least four independent processing sub-systems, each processing sub-system comprising first and second processing modules separately mounted on the backplane at adjacent locations, wherein the backplane provides at least four independent CPU-peripheral interfaces, each extending only between the adjacent locations of said first and second processing modules, the first processing module operating as a peripheral and the second processing module operating as host.
The enclosure and backplane may further provide a location for a multi-channel interface module providing external connections for all of the processing sub-systems, the backplane routing signals from the interface module to the appropriate processing sub-systems. The enclosure and backplane may further provide a location for a switching module, such that each external connection can be routed and re-routed to different processing sub-systems.
The backplane may further provide interconnections between the channel processors for communication externally of the enclosure. The enclosure and backplane may further provide a management module location for routing of said communication from the channel processors to external connectors. Said interconnections may form part of a computer local area network (LAN). The enclosure and backplane may in fact provide multiple redundant network connections in order that said onward communication can continue in the event of a network outage.
The inventors have recognised that, particularly because passive optical splitters have extremely high reliability, a probe architecture which provides for replication and redundancy in the monitoring system after the splitter would allow all the desired functionality and reliability to be achieved, without multiple physical taps in the network bearer, and hence without excessive power loss and degradation in the system being monitored.
In a fourth aspect the invention provides a multi-channel network monitoring apparatus for the monitoring of traffic in a broadband telecommunications network, the apparatus comprising:
The switching unit may further be operable to connect the same incoming channel simultaneously to more than one channel processor. The same bearer can therefore be monitored in different ways, without the need for another physical tap.
The channel processors may be in the form of modules mounted and interconnected on a common backplane. The switching unit may comprise a further module mounted on said backplane. The external input connectors may be provided by a common interface module separate from or integrated with the switching unit.
The external communication connectors may be connected to the channel processors via a communication management module and via the backplane. The external communication connectors and communication management module may optionally provide for said onward communication to be implemented over plural independent networks for redundancy. Redundancy of the networks may extend to each channel processor itself providing two or more network connections. In the particular embodiments described, the backplane provides an independent connection between each respective channel processor and the communication management module. This provides better redundancy than shared network communication.
The channel processors may each comprise a self-contained sub-system of host and peripheral processing modules interconnected via a CPU-peripheral interface in the backplane, the backplane providing a separate peripheral interface for each channel processor. The interconnection may in particular comprise a parallel peripheral interface such as cPCI.
The backplane and card-like modules may be provided in a single rack-mountchassis, which may also house a power supply and cooling fans. These may be arranged internally in accordance with the first aspect of the invention, as set forth.
The switching unit may be operable to route any incoming signal to any of the channel processors. The switching unit may further provide for routing any of the incoming channels to an further external connector, for processing by a channel processor separate from the chassis.
The invention yet further provides a network monitoring system wherein a first group of multi-channel network monitoring apparatuses according to the fourth aspect of the invention as set forth above are connected to receive a plurality of incoming signals, wherein the switching unit of each apparatus in the first group provides for routing any of its incoming channels to a further external connector, the system further comprising at least one further multi-channel network monitoring apparatus according to the fourth aspect of the invention as set forth above, connected to receive incoming channels from said further external connectors of the first group of apparatuses, the further apparatus thereby providing back-up in the event of a channel processor failure or replacement within the first group of apparatuses.
The invention yet further provides a network monitoring system wherein a plurality of multi-channel network monitoring apparatuses according to the fourth aspect of the invention as set forth above are connected to a larger plurality of incoming channels via multiplexing means, the total number of channel processors within the monitoring apparatuses being greater than the number of incoming channels at any given time, such that any incoming channel can be routed by the multiplexing means and appropriate switching unit to an idle channel processor of one of the monitoring apparatuses. This allows the system to continue monitoring all channels in the event of failure or replacement of any channel processor.
The number of channel processors may be greater than the number of incoming channels by at least the number of channel processors in each monitoring apparatus. This allows the system to continue monitoring all channels in the event of failure or replacement of one complete apparatus.
The multiplexing means may be formed by optical switches, while the switching units within each monitoring apparatus operate on signals after conversion to electrical form. Alternatively, the multiplexing means may include electronic switches, while inputs and outputs are converted to-and-from optical form for ease of interconnection between separate enclosures. In principle, the conversion from optical to electrical for could happen at any point, from the network tap point to the processing module itself.
The above systems will typically further comprise one or more multi-channel optical power splitters, for tapping into active optical communications bearers to obtain the said incoming signals for the monitoring apparatuses. The redundancy and adaptability within the monitoring system reduces the need for multiple monitoring taps, preserving the integrity of the network.
In a fifth aspect the invention provides a multi-channel replicating device for broadband optical signals, the device comprising one or more modules having:
Such a device allows multiple monitoring applications to be performed on a network signal with only one optical tap being inserted in the physical bearer or the operating network. Redundancy in the monitoring equipment can be provided, also with the single bearer tap. Change in the configuration of the monitoring equipment can be implemented without disturbing the bearer operation, or even the other monitoring applications.
The replicating means may in particular involve components for optical to electrical conversion and back to optical again.
The replicating device may further comprise an one or more additional optical outputs, and a selector devices for selecting which of the input signals is replicated at said additional output. This selection can be useful in particular in response to fault situations and planned outages within the network monitoring equipment.
The invention in the fifth aspect further provides a telecommunications network monitoring system comprising:
Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:
The payload may comprise voice traffic and/or other data. Different protocols may be catered for, with examples showing connections to Free Relay Gateway, ATM and DSLAM equipment being illustrated. User-Network traffic 22 and Network-Network traffic 24 are shown here as dashed lines and solid lines respectively.
The term “probe unit” is used herein refer to a functionally self-contained sub-system designed to carry out the required analysis for a bearer, or for a pair or larger group of bearers. Each probe unit may include separate modules to carry out such operations as filtering the packets of interest and then interpreting the actual packet or other data analysis.
In accordance with current trends, it is assumed in this description that the links to be monitored carry Internet Protocol (IP) traffic over passive optical networks (PONs) comprising optical fibre bearers. Connection to such a network can only really be achieved through use of passive optical splitters S1, S2 etc. Passive splitters have advantages such as high reliability, comparatively small dimensions, various connection configurations and the fact that no power or element management resources required. An optical splitter in such a situation works by paring off a percentage of the optical power in a bearer to a test port, the percentage being variable according to hardware specifications.
A number of issues are raised when insertion of such a device is considered. For example, there should be sufficient bearer receiver power margins remaining at both test device and the through port to the rest of the network. It becomes necessary to consider what is the most economic method of monitoring the bearer in the presence of a reduced test port power budget while limiting the optical power needed by the monitoring probe and if the network would have to be re-configured as a result of inserting the device.
Consequently, inserting a power splitter to monitor a network frequently requires an increase in launch power. This entails upgrading the transmit laser assembly and installing an optical attenuator where needed to reduce optical power into the through path to normal levels. Such an upgrade would ideally only be performed once.
For these reasons it is not desirable to probe, for example, an ATM network more than once on any given bearer. Nevertheless, it would be desirable to have the ability for multiple probing devices to be connected to the same bearer, that is, have multiple outputs from the optical interface. The different probes may be monitoring different parameters. In addition, however, any network monitoring system must offer a high degree of availability, and multiple probes are desirable in the interests of redundancy. The probe apparatuses and ancillary equipment described below allow the implementation of such a network monitoring system which can be maintained and expanded with simple procedures, with minimal disruption to the network itself and to the monitoring applications.
Network Probe System—General Architecture
The cross-point switch 80 and interconnections shown in
Detailed implementation of the probe apparatus in a specific embodiment will be described in more detail with reference to FIGS. 14 to 19. As part of this, a novel chassis arrangement for multi-channel processing products is described, with reference to
In this application example a single, fully loaded chassis 100 is used with no redundancy to monitor eight single (four duplex) bearers connected at 140 to the external optical inputs of the apparatus (inputs 70-1 to 70-N in
Recognising that in this embodiment only one optical interface is connected to the bearer under test, the chassis containing the optical interfaces can if desired have redundant communications and/or power supply units (PSUs) and adopt a “hot swap” strategy to permit rapid replacement of any hardware failures. “Hot swap” in this context means the facility to unplug one module of a probe unit within the apparatus and replace it with another without interrupting the operation or functionality of the other probe units. Higher levels of protection can be provided on top of this, if desired, as described below with reference to FIGS. 15A-C and 16.
For applications that involve processor intensive tasks it may be desirable to increase the processing power available to monitor each bearer. This may be achieved by various different configurations, and the degree of redundancy can be varied at the same time to suit each application.
In the configuration of
Thus, all eight probe units are able to apply their processing power to the same pair of signals, without tapping into the bearer more than once. By adding further chassis in such a daisy chain, processing power is scaleable practically to as much processing power as needed.
The examples given are for way of illustration only, showing how using the chassis architecture described it is possible to provide the user with the processing power needed and the redundancy to maintain operation of the of the system in the event of faults and planned outages. It will be appreciated that there are numerous different configurations possible, besides those described.
For example, it is also possible to envisage a bidirectional daisy chain arrangement. Here, one output 85 of a first chassis might be connected to one input 170 of a second chassis, while the other output 85 is connected to an input 170 of a third chassis. This arrangement can be repeated if desired to form a bi-directional ring of apparatuses, forming a kind of “optical bus”.
The probe apparatus described above allow the system designer to achieve N+1 redundancy by using the cross-point switch 80 to internally re-route a bearer to a spare processor, or to another chassis. On the other hand, it will be recognised that some types of failure (e.g. in the chassis power supply) will disrupt operation of all of the processors in the chassis. It is possible to reduce such a risk by providing N+1 PSU redundancy, as will be/has been described.
Broadband Bridging Isolator
Also provided within BBI 172 are one or more standby selectors (multiplexers) 180 (one only shown). Each selector 180 receives replicas of the input signals and can select from these a desired one to be replicated at a selector optical output 182. An additional input 186 (shown in broken lines) may be provided which passes to the selector 180 without being replicated, to permit “daisy chain” connection.
In use, BBI 172 takes a single tap input 176 from a bearer being monitored and distributes this to multiple monitoring devices, for example probe apparatuses of the type shown in FIGS. 3 to 10. For reliability, the standby selector 180 allows any of the input signals to be switched to a standby chassis.
The number of outputs that are duplicated from each input is not critical. A typical implementation may provide four, eight or sixteen replicators 175 in a relatively small rack mountable chassis, each having (for example) four outputs per input. Although the concepts here are described in terms of optical bearers, the same concepts could be applied to high speed electrical bearers (e.g. E3, DS3 and STM1e).
The reasons for distributing the signal could be for multiple applications, duplication for reliability, load sharing or a combination of all three. It is important that only one tap need be made in the operational bearer. As described in the introductory part of this specification, each optical tap reduces the strength of the optical signal reaching the receiver. In marginal conditions, adding a tap may require boosting the signal on the operational bearer. Network operators do not want to disrupt their operational networks unless they have to. The BBI allows different monitoring apparatuses for different applications to be connected, and removed and re-configured without affecting the operational bearer, hence the name “isolator”. The BBI can even be used to re-generate this signal by feeding one of the outputs back into the network, so that the BBI becomes part of the operational network.
The number of bearer signals that are switched through the standby selector 180 will depend on the users requirements—this number corresponds effectively to “N” in the phrase “N+1 redundancy”. The number of standby selectors in each BBI is not critical. Adding more means that more bearers can be switched should there be a failure.
The BBI must have high reliability as when operational in a monitoring environment it an essential component in the monitoring of data, providing the only bridging link between the signal bearers and the probe chassis. No digital processing of the bearer signal is performed in the BBI, which can thus be made entirely of the simplest and most reliable optoelectronic components. When technology permits, in terms of cost and reliability, there may be an “all-optical” solution, which avoids conversion to electrical form and back to optical. Presently, however, the state of the art favours the optoelectronic solution detailed here. The BBI can be powered from a redundant power supply to ensure continuous operation. The number of bearers handled on a single card can be kept small so that in event of a failure the number of bearers impacted is small. The control of the standby switch can be by an external control processor.
Using the standby selector 180 any one of the bearers can be switched through to the standby chassis 130 in the event of a failure of a probe unit in one of the main probe chassis 100-1, 100-2. It will be appreciated that, if there is a failure of a complete probe chassis, then only one of the bearers can be switched through to the standby probe. In a larger system with, say, 16 duplex bearers, four main probe chassis and two standby chassis, the bearers distributed by each BBI can be shared around the probe chassis so that each probe chassis processes one bearer from each BBI. Then all four bearers can be switched to the standby probe in the event of a complete chassis failure.
It will be seen that the BBI offers increased resilience for users particularly when they have multiple departments wanting to look at the same bearers. The size of the BBI used is not critical and practical considerations will influence the number of inputs and outputs. For example, the BBI could provide inputs for 16 duplex bearers, each being distributed to two or three outputs with four standby outputs. Where multiple standby circuits are used each will be capable of being independently switched to any of the inputs.
In this example the processing power has been doubled from one probe unit per bearer to two probe units per bearer but it can be seen that such a scheme could be easily extended by connecting further chassis. At no point has the original monitoring capacity been lost, and at no point have the bearers themselves (not shown) been disrupted. Thus, for example, a module of one probe unit can be removed for upgrade while other units continue their own operations. If there is spare capacity, one of the other units can step in to provide the functionality of the unit being replaced. After Step 2, the entire first chassis 100-1 could be removed and replaced while the second chassis 100-2 steps in to perform its functions. Variations on this method are practically infinite, and can also be used for other types of migration, such as when increasing system reliability.
The hardware and methods used in these steps can be arranged to comply with “hot-swap” standards as defined earlier. The system of
Multi-channel Probe Apparatus—Functional arrangement
A network interface module 200 provides optical fibre connectors for the incoming bearer signals EXT 1-8 (70-1 to 70-N in
LAN and chassis management modules 230, 235 (which in the implementation described later are combined on a single card) provide central hardware platform management and onward communication of the processing results. For this onward communication, multiple redundant LAN interfaces are provided between every SBC 160 and the LAN management module 230 across the backplane. The LAN management function has four LAN inputs (one from each SBC) and four LAN outputs (for redundancy) to the monitoring LAN network. Multiple connections are provided as different SBC manufacturers use different pin connectors on their connectors. For any particular manufacturer there is normally only one connection between the SBC 160 and the LAN management module 230. The dual redundant LAN interfaces are provided for reliability in reporting the filtered and processed data to the next level of aggregation (site processor 40 in
The chassis management module 235 oversees monitoring and wiring functions via (for example) an I2C bus using various protocols. Although I2C is normally defined as a shared bus system, each probe unit for reliability has its own I2C connection direct to the management module. The management module can also instruct the cross-point switch to activate the “spare” output (labelled as monitoring channels CH9,10 and optical outputs EXT 9,10) when it detects failure of one of the probe unit modules. This operation can also be carried out under instruction via LAN.
The network probe having the architecture described above must be realised in a physical environment capable of fulfilling the functional specifications and other hardware platform considerations such as the telecommunications environment it is to be deployed in. A novel chassis (or “cardcage”) configuration has been developed to meet these requirements within a compact rack-mountable enclosure. The chassis is deployed as a fundamental component of the data collection and processing system.
Multi-channel Probe Apparatus—Physical Implementation
A LAN & Chassis Management module 230 is provided, which is connected to the other modules by I2C buses in the backplane, and by LAN connections. A LAN interface module 270 provides external LAN connections for the onward reporting of processing results. Also provided is a fan assembly 400 for cooling and a power supply (PSU) module 420.
Referring to the views in
In the present chassis, the power supply module (PSU) 420 is located in a shallow space behind the backplane 190. The processing modules 150-1, 160-1 etc. at the front of the backplane are, moreover, arranged to lie horizontally, with their long axes parallel to the front panel. The cooling fans 400 are placed to one side of the chassis. Airflow enters the chassis at the front at 410 and flows horizontally over the components to be cooled, before exiting at the rear at 412. This arrangement gives the chassis a high cooling capability while at the same time not extending the size of the chassis beyond the desired dimensions. The outer dimensions and front flange of the housing allow the chassis to be mounted on a standard 19 inch (483 mm) equipment rack, with just 5U height. Since the width of the enclosure is fixed by standard rack dimensions, but the height is freely selectable, the horizontal arrangement allows the space occupied by the enclosure to be matched to the number of processor slots required by the application. In the known vertical orientation, a chassis which provides ten slots must be just as high as one which provides twenty slots, and additional height must be allowed for airflow arrangements at top and bottom.
Referring also to
Other connector positions are used differently by different manufacturers. Eight of the front slots (F1-F8) support the Packet Processor/SBC cards in pairs. The cards are removable using ‘hot swap’ techniques, as previously outlined, using thumb levers 195 to lock/unlock the cards and to signal that a card is to be inserted/removed. The other two front slots F9 and F10 are used for cross-point switch 80 and LAN/Management card 230 respectively. Slots F1 to F8 comply with the cPCI insofar as connectors J1, J2, J3 and J5 are concerned. Other bus standards such as VME could be also be used. The other slots F9 and F10 are unique to this design. All of the cPCI connections are standard and the connectivity, routing and termination requirements are taken from the cPCI standard specification. Keying requirements are also taken from the cPCI standard. The cPCI bus does not connect all modules, however: it is split into four independent buses CPCI1-4 to form four self-contained host-peripheral processing sub-systems. Failure of any packet processor/SBC combination will not affect the other three probe units.
Each of the cards is hot-swappable and will automatically recover from any reconfiguration. Moreover, by providing switches responsive to operation of the thumb levers 195, prior to physical removal of the card, the system can be warned of impending removal of an module. This warning can be used to trigger automatic re-routing of the affected monitoring channel(s). The engineer replacing the card can be instructed to await a visual signal on the front panel of the card or elsewhere, before completing the removal of the card. This signal can be sent by the LAN/Management module 270, or by a remote controlling site. This scheme allows easy operation for the engineer, without any interruption of the monitoring functions, and without special steps to command the re-routing. Such commands might otherwise require the co-ordination of actions at the local site with staff at a central site, or at best the same engineer might be required to move between the chassis being worked upon and a nearby PC workstation.
As mentioned above, the upper two front slots (F10, F9) hold the LAN & Management module 230 and the cross-point switch 80 respectively. Slot B1 (behind F9) carries a Network Transition card forming network interface module 200, while the LAN interface 270 in slot B2 (behind F10) carries the LAN connectors. All external connections are to the apparatus are provided by special transition cards in these rear slots, and routed through the backplane. No cabling needs to reach directly the rear of the individual probe unit slots. No cabling at all is required to the front of the enclosure. This is not only tidy externally of the housing, but leaves a clear volume behind the backplane which can be occupied by the PSU 420, shown cut-away in
The J4 position in the backplane is customised to route high integrity network signals (labelled “RF” in
The backplane also carries I2C buses (SMB protocol) and the LAN wiring. These are carried to each SBC 160-1 etc. either in the J3 position or the J5 position, depending on the manufacturer of the particular SBC, as described later. The LAN interface module 270 provides the apparatus with two external LAN ports for communications to the next layer of data processing/aggregation, for example a site processor.
Connectivity is achieved using two LANs (A and B) at 100 BaseT for a cardcage. The LAN I/O can be arranged to provide redundant connection to the external host computer 40. This may be done, for example, by using four internal LAN connection and four external LAN connections routed via different segments of the LAN 60. It is therefore possible to switch any SBC to either of the LAN connections such that any SBC may be on any one connection or split between connections. This arrangement may be changed dynamically according to circumstances, as in the case of an error occurring, and allows different combinations of load sharing and redundancy. Additionally, this allows the probe processors to communicate with each other without going on the external LAN. However, this level of redundancy in the LAN connection cannot be achieved if the total data from the probe processors exceeds the capacity of any one external LAN connection.
An external timing port (not shown in
The individual modules will now be described in detail, with reference to FIGS. 17 19. This will further clarify the inter-relationships between them, and the role of the backplane 190 and chassis 100.
Cross-Point Switch Module 80
The outputs to the packet processors (CH1-CH4) are via the backplane 190 (position J4,
The external optical outputs EXT 9,10 are provided via transmit interface 310 of the module 200 for connecting to a spare chassis (as in
Although functionally each multiplexer M of the cross-point switch is described and shown as being controlled by a respective packet processor 150, in the present embodiment this control is conducted via the LAN & management module 230. Commands or requests for a particular connection can be sent to the LAN & management module from the packet processor (or associated SBC 160) via the LAN connections, or I2C buses, provided in connectors J3 or J5.
Packet Processor Module 150
The following description makes reference to a single “half” of the two-channel packet processor module 150, and to a single Packet Processor/SBC pair only (single channel). The chassis as described supports four such Packet Processor/SBC pairs, and each packet processor comprises two processing means to handle multiple bearer signals (multiple monitoring channels).
It is possible for the Packet Processor 150 to filter the incoming data. This is essential due to the very high speed of the broadband network interfaces being monitored, such as would be the case for OC-3 and above. The incoming signals are processed by the Packet Processor, this generally taking the form of time stamping the data and performing filtering based on appropriate fields in the data. Different fields can be chosen accordingly, for example ATM cells by VPI/NVCI (VC) number, IP by IP address, or filtering can be based on other, user defined fields. It is necessary to provide the appropriate means to recover the clock and data from the incoming signal, as the means needed varies dependent on link media and coding schemes used. In a typical example using ATM, ATM cells are processed by VPI/NVCI (VC) number. The Packet Processor is provided with means 320 to recover the clock and data from the incoming signal bit stream. The data is then ‘deframed’ at a transmission convergence sub-layer 330 to extract the ATM cells. The ATM cells are then time-stamped 340 and then buffered in a First In First Out (FIFO) buffer 350 to smooth the rate of burst type data. Cells from this FIFO buffer are then passed sequentially to an ATM cell processor 360. The packet processor can store ATM cells to allow it to re-assemble cells into a message—a Protocol Data Unit (PDU). Only when the PDU has been assembled will it be sent to the SBC. Before assembly, the VC of a cell is checked to ascertain what actions should be taken, for example, to discard cell, assemble PDU, or pass on the raw cell.
Data is transferred into the SBC memory using cPCI DMA transfers to a data buffer 38. This ensures the very high data throughput that may be required if large amounts of data are being stored. The main limitation in the amount of data that is processed will be due to the applications software that processes it. It is therefore the responsibility of the Packet Processor 150 to carry out as much pre-processing of the data as possible so that only that data which is relevant is passed up into the application domain.
The first function of the Packet Processor 150 is to locate the instructions for processing the VC (virtual channel or ) to which the cell belongs. To do this it must convert the very large VPI/VCI of the cell into a manageable pointer to its associated processing instructions (VC # key). This is done using a hashing algorithm by hash generator 390, which in turn uses a VC hash table. Processor 150, having located the instructions, can then process the cell.
Processing the cell involves updating status information for the particular VC (e.g. cell count) and forwarding the cell and any associated information (e.g. “Protocol Data Unit (PDU) received”) to the SBC 160 if required. By reading the status of a particular VC, the processor can vary its action depending on the current status of that VC (e.g. providing summary information after first cell received). Cell processor 360 also requires certain configurable information which is applicable to all of its processing functions regardless of VC (e.g. buffer sizes) and this ‘global’ configuration is accessible via a global configuration store.
A time stamping function 340 can be synchronised to an external GPS time signal or can be adjusted by the SBC 160. The SBC can also configure and monitor the ‘deframer’ (e.g. set up frame formats and monitor alarms) as well as select the optical inputs (EXT 1-8) to be monitored. Packet Processor 150 provides all of the necessary cPCI interface functions.
Each packet processor board 150-1 etc. is removable without disconnecting power from the chassis. This board will not impact the performance of other boards in the chassis other than the associated SBC. The microprocessor notifies the presence or absence of the packet processor and processes any signal loss conditions generated by the Packet Processor.
Single Board Computer (SBC) Modules 160
The SBC module 160 is not shown in detail herein, being a general-purpose processing module, examples including the Motorola CPV5350, FORCE CPCI-730, and SMT NAPA. The SBC 150 is a flexible, programmable device. In this specific embodiment two such devices may exist on one cPCI card, in the form of “piggyback” modules (PMCs). The 100 BaseT interfaces, disk memory etc. may also be in the form of PMCs. As already described, communications via the cPCI bus (J1/J2) on the input side and via the LAN port on the output side and all other connections are via the backplane at the rear, unless for diagnostic purposes for which an RS-232 port is provided at the front.
LAN & Chassis Management Module 230
On the chassis management side, a Field Programmable Gate Array (FGPA) 510 within this module performs the following functions:
A hardware watchdog feature 560 is also included to monitor the activity of all modules and take appropriate action in the event that any of them becomes inactive or unresponsive. This includes the ability to reset modules.
Finally, the management module implements at 580 “Multivendor Interconnect”, whereby differences in the usage of cPCI connectors pins (or whatever standard is adopted) between a selection of processor vendors can be accommodated.
As mentioned previously, the chassis carries at some locations, cPCI processor modules from a choice of selected vendors, but these are coupled via cPCI bus to special peripheral cards. While such cards are known in principle, and the processor-peripheral bus is fully specified, the apparatus described does not have a conventional interconnect arrangement for the broadband signals, multiple redundant LAN connections and so forth. Even for the same functions, such as the LAN signals and I2C/SMB protocol for hardware monitoring, different SBC vendors place the relevant signals on different pins of the cPCI connector set, particularly they may be on certain pins in J3 with some vendors, and on various locations in J5 with others. Conventionally, this means that system designer has to restrict the user's choice of SBC modules to those of one vendor, or a group of vendors who have adopted the same pin assignment for LAN and SMB functions, besides the standard assignments for J1, and J2 which are specified for all cPCI products.
To overcome this obstacle a modular Multivendor Interconnect (MVI) solution may be applied. The MVI module 580 is effectively four product-specific configuration cards that individually route the LAN and SMB signals received from each SBC 160-1 etc. to the correct locations on the LAN/Management cards. One MVI card exists for each processor. These are carried piggyback on the LAN/management module 230, and each is accessible from the front panel of the enclosure. The backplane in locations J3 and J5 includes sufficient connectors, pins and interconnections between the modules to satisfy a number of different possible SBC types. Needless to say, when replacing a processor card with one of a different type, the corresponding MVI configuration card needs exchanging also.
An alternative scheme to switch the card connection automatically based on vendor ID codes read via the backplane can also be envisaged. In a particular embodiment, for example, the “Geographic Address” pins defined in the cPCI connector specifications may be available for signalling (under control of a start-up program) which type of SBC 160 is in a given slot. The routing of SMB, LAN and other signals can then be switched electronically under control of programs in the LAN & management card 230.
Those skilled in the art will recognise that the invention in any of its aspects is not limited to the specific embodiments disclosed herein. In particular, unless specified in the claims, the invention is in no way limited to any particular type of processor, type of network to be monitored, protocol, choice of physical interconnect, choice of peripheral bus (cPCI v. VME, parallel v. serial etc.), number of bearers per chassis, number of bearers per monitoring channel, number of monitoring channels per probe unit.
The fact that independent processor subsystems are arranged in the chassis allows multiple data paths from the telecommunications network to the LAN network, thereby providing inherent redundancy. On the other hand, for other applications such as computer telephony, reliability and availability may not be so critical as in the applications addressed by the present embodiment. For such applications, a similar chassis arrangement but with H.110 bus in the backplane may be very useful. Similarly, the cPCI bus, I2C bus and/or LAN interconnect may be shared among all the modules,
Each aspect of the invention mentioned above is to be considered as independent, such that the probe functional architecture can be used irrespective of the chassis configuration, and vice versa. On the other hand, the reader will recognise that the specific combinations of these features offers in a highly desirable instrumentation system, which provides the desired functionality, reliability and availability levels in a compact and scalable architecture.
In the specific embodiments described herein, each probe unit comprising first and second processor modules (the packet processor and SBC respectively) is configured to monitor simplex and duplex bearers. The invention, in any of its aspects, is not limited to such embodiments. In particular, each probe unit may be adapted to process one or more individual bearer signals. In the case of lower speed protocol signals the bearer signals can be multiplexed together (for example within the cross-point switch module 80 or network interface module 200) to take full advantage of the internal bandwidth of the architecture.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4978953 *||Nov 22, 1988||Dec 18, 1990||Technology 80, Inc.||Device for monitoring multiple digital data channels|
|US5163052 *||Oct 12, 1989||Nov 10, 1992||Ncr Corporation||High reliability computer diagnostics system|
|US5457729 *||Feb 7, 1995||Oct 10, 1995||Symmetricom, Inc.||Communication network signalling system link monitor and test unit|
|US5522042 *||Jan 28, 1994||May 28, 1996||Cabletron Systems, Inc.||Distributed chassis agent for distributed network management|
|US5560033 *||Aug 29, 1994||Sep 24, 1996||Lucent Technologies Inc.||System for providing automatic power control for highly available n+k processors|
|US5649100 *||Aug 25, 1994||Jul 15, 1997||3Com Corporation||Network backplane interface having a network management section for managing and configuring networks on the backplane based upon attributes established in a parameter table|
|US5751932 *||Jun 7, 1995||May 12, 1998||Tandem Computers Incorporated||Fail-fast, fail-functional, fault-tolerant multiprocessor system|
|US5771225 *||Jan 22, 1996||Jun 23, 1998||Fujitsu Limited||System for adjusting characteristic of protection unit when switching from plural working units having various characteristics to protection unit|
|US6012151 *||Apr 21, 1997||Jan 4, 2000||Fujitsu Limited||Information processing apparatus and distributed processing control method|
|US6021111 *||Dec 6, 1996||Feb 1, 2000||Nec Corporation||Unit switching apparatus with failure detection|
|US6081503 *||Oct 1, 1997||Jun 27, 2000||Lucent Technologies Inc.||Control architecture using an embedded signal status protocol|
|US6324608 *||Oct 1, 1997||Nov 27, 2001||Micron Electronics||Method for hot swapping of network components|
|US6484126 *||Sep 17, 1999||Nov 19, 2002||Westinghouse Electric Company Llc||Digital plant protection system with engineered safety features component control system|
|US6532089 *||Aug 19, 1999||Mar 11, 2003||Nec Corporation||Optical cross-connect, method of switching over optical path, optical ADM, and optical cross-connect network system|
|US6636922 *||Mar 15, 2000||Oct 21, 2003||Adaptec, Inc.||Methods and apparatus for implementing a host side advanced serial protocol|
|US6859882 *||May 18, 2001||Feb 22, 2005||Amphus, Inc.||System, method, and architecture for dynamic server power management and dynamic workload management for multi-server environment|
|US6988221 *||May 17, 2004||Jan 17, 2006||Triconex||Method and apparatus for processing control using a multiple redundant processor control system|
|US20020032842 *||Aug 30, 2001||Mar 14, 2002||Shigeo Kawauchi||Data acquisition apparatus and memory controller|
|US20030033393 *||Aug 7, 2001||Feb 13, 2003||Larson Thane M.||System and method for providing network address information in a server system|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7187687||May 6, 2002||Mar 6, 2007||Foundry Networks, Inc.||Pipeline method and system for switching packets|
|US7573898 *||Dec 29, 2003||Aug 11, 2009||Fujitsu Limited||Method and apparatus to double LAN service unit bandwidth|
|US7636318 *||Dec 1, 2006||Dec 22, 2009||Solana Networks Inc.||Real-time network analyzer|
|US7649885 *||May 6, 2002||Jan 19, 2010||Foundry Networks, Inc.||Network routing system for enhanced efficiency and monitoring capability|
|US7657703||Apr 28, 2005||Feb 2, 2010||Foundry Networks, Inc.||Double density content addressable memory (CAM) lookup scheme|
|US7738450||Jul 25, 2007||Jun 15, 2010||Foundry Networks, Inc.||System architecture for very fast ethernet blade|
|US7778207||Nov 15, 2006||Aug 17, 2010||Light Greta L||Passive tap and associated system for tapping network data|
|US7787400||Jul 11, 2007||Aug 31, 2010||Light Greta L||Passive network tap with digital signal processing for separating signals|
|US7809476 *||May 31, 2006||Oct 5, 2010||Cicchetti Christopher J||Network tap/aggregator configured for power over ethernet operation|
|US7809960||May 31, 2006||Oct 5, 2010||Cicchetti Christopher J||Network tap device powered by power over ethernet|
|US7813365||Nov 14, 2005||Oct 12, 2010||Foundry Networks, Inc.||System and method for router queue and congestion management|
|US7813367||Jan 8, 2007||Oct 12, 2010||Foundry Networks, Inc.||Pipeline method and system for switching packets|
|US7817540 *||May 8, 2002||Oct 19, 2010||Cisco Technology, Inc.||Method and apparatus for N+1 RF switch with passive working path and active protection path|
|US7817659||Mar 26, 2004||Oct 19, 2010||Foundry Networks, Llc||Method and apparatus for aggregating input data streams|
|US7830884||Sep 12, 2007||Nov 9, 2010||Foundry Networks, Llc||Flexible method for processing data packets in a network routing system for enhanced efficiency and monitoring capability|
|US7848253||Mar 19, 2008||Dec 7, 2010||Mcdata Corporation||Method for scoring queued frames for selective transmission through a switch|
|US7860033||Jul 11, 2007||Dec 28, 2010||Light Greta L||Passive network tap with bidirectional coupler and associated splitting methods|
|US7860034||Jul 11, 2007||Dec 28, 2010||Light Greta L||Receive only physical interface device IC used in a passive network tap|
|US7903654||Dec 22, 2006||Mar 8, 2011||Foundry Networks, Llc||System and method for ECMP load sharing|
|US7948872||Mar 9, 2009||May 24, 2011||Foundry Networks, Llc||Backplane interface adapter with error control and redundant fabric|
|US7953922||Dec 16, 2009||May 31, 2011||Foundry Networks, Llc||Double density content addressable memory (CAM) lookup scheme|
|US7953923||Dec 16, 2009||May 31, 2011||Foundry Networks, Llc||Double density content addressable memory (CAM) lookup scheme|
|US7974208||May 10, 2010||Jul 5, 2011||Foundry Networks, Inc.||System and method for router queue and congestion management|
|US7978614||Dec 10, 2007||Jul 12, 2011||Foundry Network, LLC||Techniques for detecting non-receipt of fault detection protocol packets|
|US7978702||Feb 17, 2009||Jul 12, 2011||Foundry Networks, Llc||Backplane interface adapter|
|US7995580||Mar 9, 2009||Aug 9, 2011||Foundry Networks, Inc.||Backplane interface adapter with error control and redundant fabric|
|US8000321 *||Oct 19, 2006||Aug 16, 2011||Alcatel Lucent||Method and apparatus for improved non-intrusive monitoring functions|
|US8014315||Oct 21, 2009||Sep 6, 2011||Mcdata Corporation||Method for scoring queued frames for selective transmission through a switch|
|US8027277||Nov 15, 2006||Sep 27, 2011||Jds Uniphase Corporation||Passive network tap for tapping network data|
|US8037399||Jul 18, 2007||Oct 11, 2011||Foundry Networks, Llc||Techniques for segmented CRC design in high speed networks|
|US8090901||May 14, 2009||Jan 3, 2012||Brocade Communications Systems, Inc.||TCAM management approach that minimize movements|
|US8117299 *||Jan 18, 2005||Feb 14, 2012||Lenovo (Singapore) Pte. Ltd.||Method and apparatus for scheduling wireless LAN traffic|
|US8149839||Aug 26, 2008||Apr 3, 2012||Foundry Networks, Llc||Selection of trunk ports and paths using rotation|
|US8155011||Dec 10, 2007||Apr 10, 2012||Foundry Networks, Llc||Techniques for using dual memory structures for processing failure detection protocol packets|
|US8170044||Jun 7, 2010||May 1, 2012||Foundry Networks, Llc||Pipeline method and system for switching packets|
|US8190881||Oct 15, 2007||May 29, 2012||Foundry Networks Llc||Scalable distributed web-based authentication|
|US8238255||Jul 31, 2007||Aug 7, 2012||Foundry Networks, Llc||Recovering from failures without impact on data traffic in a shared bus architecture|
|US8271859||Jul 18, 2007||Sep 18, 2012||Foundry Networks Llc||Segmented CRC design in high speed networks|
|US8395996||Dec 10, 2007||Mar 12, 2013||Foundry Networks, Llc||Techniques for processing incoming failure detection protocol packets|
|US8448162||Dec 27, 2006||May 21, 2013||Foundry Networks, Llc||Hitless software upgrades|
|US8493988||Sep 13, 2010||Jul 23, 2013||Foundry Networks, Llc||Method and apparatus for aggregating input data streams|
|US8509236||Aug 26, 2008||Aug 13, 2013||Foundry Networks, Llc||Techniques for selecting paths and/or trunk ports for forwarding traffic flows|
|US8514716||Jun 4, 2012||Aug 20, 2013||Foundry Networks, Llc||Backplane interface adapter with error control and redundant fabric|
|US8599850||Jan 7, 2010||Dec 3, 2013||Brocade Communications Systems, Inc.||Provisioning single or multistage networks using ethernet service instances (ESIs)|
|US8619781||Apr 8, 2011||Dec 31, 2013||Foundry Networks, Llc||Backplane interface adapter with error control and redundant fabric|
|US8667268||May 1, 2012||Mar 4, 2014||Foundry Networks, Llc||Scalable distributed web-based authentication|
|US8671219||May 7, 2007||Mar 11, 2014||Foundry Networks, Llc||Method and apparatus for efficiently processing data packets in a computer network|
|US8718051||Oct 29, 2009||May 6, 2014||Foundry Networks, Llc||System and method for high speed packet transmission|
|US8730961||Apr 26, 2004||May 20, 2014||Foundry Networks, Llc||System and method for optimizing router lookup|
|US8737235||Dec 11, 2009||May 27, 2014||Cavesson Software Llc||Real-time network analyzer|
|US8799645||Apr 27, 2012||Aug 5, 2014||Foundry Networks, LLC.||Scalable distributed web-based authentication|
|US8811390||Oct 29, 2009||Aug 19, 2014||Foundry Networks, Llc||System and method for high speed packet transmission|
|US8935568||Jul 27, 2012||Jan 13, 2015||Dell Products, Lp||System and method of replicating virtual machines for live migration between data centers|
|US8964754||Nov 8, 2013||Feb 24, 2015||Foundry Networks, Llc||Backplane interface adapter with error control and redundant fabric|
|US8989202||Feb 16, 2012||Mar 24, 2015||Foundry Networks, Llc||Pipeline method and system for switching packets|
|US9030937||Jul 11, 2013||May 12, 2015||Foundry Networks, Llc||Backplane interface adapter with error control and redundant fabric|
|US9030943||Jul 12, 2012||May 12, 2015||Foundry Networks, Llc||Recovering from failures without impact on data traffic in a shared bus architecture|
|US9104645||Jul 27, 2012||Aug 11, 2015||Dell Products, Lp||System and method of replicating virtual machines for live migration between data centers|
|US9112780||Feb 13, 2013||Aug 18, 2015||Foundry Networks, Llc||Techniques for processing incoming failure detection protocol packets|
|US20050147121 *||Dec 29, 2003||Jul 7, 2005||Gary Burrell||Method and apparatus to double LAN service unit bandwidth|
|US20050175018 *||Nov 29, 2004||Aug 11, 2005||Wong Yuen F.||System and method for high speed packet transmission implementing dual transmit and receive pipelines|
|US20050226148 *||Dec 29, 2004||Oct 13, 2005||Nortel Networks Limited||Method and apparatus for enabling redundancy in a network element architecture|
|US20060062233 *||Nov 14, 2005||Mar 23, 2006||Chiaro Networks Ltd.||System and method for router queue and congestion management|
|US20060160508 *||Jan 18, 2005||Jul 20, 2006||Ibm Corporation||Method and apparatus for scheduling wireless LAN traffic|
|US20120295674 *||Nov 22, 2012||By Light Professional IT Services||Systems, methods and devices for convergent communications|
|WO2007144698A2 *||Oct 17, 2006||Dec 21, 2007||Sylvio Bisson||Methods and systems for scalable interconnect|
|International Classification||H04L12/26, G06F11/00, H04L12/66|
|Cooperative Classification||H04L49/555, H04L43/00, H04L12/2602|
|European Classification||H04L12/26M, H04L43/00|
|Jul 27, 2004||AS||Assignment|
Owner name: AGILENT TECHNOLOGIES, INC., CALIFORNIA
Free format text: ASSIGNMENT BY OPERATION OF LAW;ASSIGNORS:HEWLETT-PACKARD LIMITED;REYNOLDS, ALASTAIR;CARSON, DOUGLASJOHN;AND OTHERS;REEL/FRAME:015658/0814
Effective date: 20040424
|Oct 18, 2005||AS||Assignment|
Owner name: AGILENT TECHNOLOGIES, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:HEWLETT-PACKARD LIMITED;REYNOLDS, ALASTAIR;CARSON, DOUGLAS JOHN;AND OTHERS;REEL/FRAME:016897/0584
Effective date: 20010424