Source: http://www.google.com/patents/US7876693?ie=ISO-8859-1&dq=6076065
Timestamp: 2015-07-02 11:00:30
Document Index: 641561089

Matched Legal Cases: ['art 400', 'art 600', 'art 400', 'art 400', 'art 600', 'art 600', 'art 400', 'art 400']

Patent US7876693 - Testing and error recovery across multiple switching fabrics - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsA packet-based traffic switching system with error detection and correction without taking the system offline. The system tests offline paths without interfering with other online paths. Also, the system tests online paths even while no data cell traffic is sent over the paths. The system responds to...http://www.google.com/patents/US7876693?utm_source=gb-gplus-sharePatent US7876693 - Testing and error recovery across multiple switching fabricsAdvanced Patent SearchPublication numberUS7876693 B2Publication typeGrantApplication numberUS 10/453,976Publication dateJan 25, 2011Filing dateJun 4, 2003Priority dateJun 4, 2002Fee statusPaidAlso published asUS20040037277Publication number10453976, 453976, US 7876693 B2, US 7876693B2, US-B2-7876693, US7876693 B2, US7876693B2InventorsGregory S. Mathews, Eric Anderson, Philip Ferolito, Mike MorrisonOriginal AssigneeAlcatel-Lucent Usa Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (5), Referenced by (3), Classifications (10), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetTesting and error recovery across multiple switching fabrics
US 7876693 B2Abstract
A packet-based traffic switching system with error detection and correction without taking the system offline. The system tests offline paths without interfering with other online paths. Also, the system tests online paths even while no data cell traffic is sent over the paths. The system responds to the addition or removal of paths or path components without interrupting cell traffic. The system detects and selectively flushes defective paths without impacting paths that are working properly. The system initializes new switching fabrics automatically without using software to set values. Thus, the system tests online paths and corrects errors without going offline.
This application is entitled to the benefit of provisional Patent Application Ser. No. 60/385,863, filed Jun. 4, 2002. This application incorporates by reference co-pending patent application serial number (TBD), filed herewith, entitled “OPTIMAL LOAD BALANCING ACROSS MULTIPLE SWITCHING FABRICS”.
The present invention relates generally to packet-based traffic forwarding, and more particularly to testing and error recovery across multiple switching fabrics in a packet-switched network node.
Packet-switched networks are responsible for forwarding packet-based traffic. In some hardware devices, such as switches and routers, a system breaks packets into fixed-length cells and forwards the cells from an ingress, across a switching fabric, to an egress, where the system typically reassembles the cells into packets.
Systems with multiple switching fabrics may forward cells in parallel or serially. These configurations are discussed in co-pending patent application serial number (TBD), entitled “OPTIMAL LOAD BALANCING ACROSS MULTIPLE SWITCHING FABRICS”, which is incorporated herein by reference. As the number of data paths grows, error detection, error correction, and system maintenance become more complex. More data paths means more chances for data paths to fail. Moreover, systems with many data paths may require more hardware components, such as multiple switching fabrics. Swapping components in and out of a system can cause more frequent failures.
In view of the desire to perform error recovery and other maintenance in a system with multiple switching fabrics, what is needed is a means for performing online diagnostics. In addition, it would be advantageous to perform offline diagnostics for some data paths without interfering with data transmission on other paths. This would enable the system to remain online while diagnosing some paths offline. It would further be advantageous to detect errors across a given path even when no data is transmitted along the given path. This would enable the system to differentiate between “no traffic” and a “broken path”. It would further be advantageous to facilitate the addition and removal of switching fabrics while seamlessly transmitting traffic. This would enable changing, maintaining, or upgrading system hardware without taking the system offline. It would further be advantageous to detect nonfunctional queues in the switching fabric and respond by selectively flushing the nonfunctional queues, thereby limiting the impact on other system resources. It would be further advantageous to provide automatic initialization of newly added switching fabrics. It would be further advantageous to perform online detection and correction of errors.
A technique for performing error recovery in a system with multiple switching fabrics includes testing ingress-to-egress paths across the switching fabrics while the system is online. In an embodiment, this technique includes offline testing for some paths without interfering with other online paths. In another embodiment, the technique includes the testing of online paths even while no data cell traffic is sent over the paths. In another embodiment, the technique includes responding to the addition or removal of paths or path components without interrupting cell traffic forwarding. In another embodiment, the technique includes detecting and selectively flushing defective paths without impacting paths that are working properly. In another embodiment, the technique includes initializing new switching fabrics automatically without using software to set values. In another embodiment, the technique includes testing online paths and correcting errors without going offline.
FIG. 1 is a block diagram of a traffic forwarding system.
As shown in the drawings for the purposes of illustration, an embodiment of the invention tests for and recovers from errors in a traffic forwarding system, having multiple switching fabric modules, configured for use in a network with packet-based traffic. An exemplary traffic forwarding system is described in co-pending patent application serial number (TBD), entitled “OPTIMAL LOAD BALANCING ACROSS MULTIPLE SWITCHING FABRICS” and bearing, which has been incorporated by reference.
After the ingress receive module 222 enqueues cells in the ingress queues 224, the ingress queues 224 wait for the ingress transmit module 226 to determine which cells to transmit. The ingress transmit module 226 also considers test cells in the determination. The ingress diagnostics module 228 generates test cells. The system treats test cells much like any other cell, but the test cells are often assigned a high (e.g., a control) priority. The transmit module 226 stripes the data and test cells across HSIs 210 according to, for example, an arbitration algorithm. The transmit module 226 then recycles the pointers used to tokenize the cells. In an embodiment, the ingress transmit module 226 consults an active fabric mask (AFM), which is set by the ingress diagnostics module 228, to determine which switching fabrics are enabled to transmit data cells and non-diagnostic test cells (i.e., included in the striping sequence). In another embodiment, the ingress transmit module 226 consults a test fabric mask (TFM), which is set by the ingress diagnostics module 228, to determine which switching fabrics are enabled to transmit diagnostic test cells. For example, for 4 switching fabrics 0 to 3, an AFM of ‘1101’ indicates the switching fabrics 0, 1, and 3 are enabled for data transmission. A TFM of ‘0010’ indicates the switching fabrics 2 is enabled for testing. Accordingly, the ingress transmit module 226 stripes data cells across the switching fabrics 0, 1, and 3, skipping switching fabric 2, and the ingress transmit module 226 transmits diagnostic test cells across switching fabric 2. It should be noted that the switching fabrics could be enabled for both data and diagnostic testing simultaneously. In another embodiment, switching fabrics enabled for data transmission cannot be enabled for diagnostic test cells (i.e., AFM overrides TFM). The AFM and TFM thereby facilitate efficient arbitration between cells that are contending for transmission across the switching fabrics.
The SOP flag 312 is set if a packet is broken into portions and the payload 330 of the cell 300A includes the first portion of the packet. The MC flag 314 is set if the packet is multicast and not set if the packet is unicast. The priority field 316 contains the priority of the packet. In an embodiment, the priority field 316 is 3 bits long, which allows the priority field 316 to represent up to 8 priorities. In another embodiment, packets having different priorities are forwarded to and from and reassembled in different queues. The EOP flag 318 is set if the payload 330 of the cell 300A includes the last portion of the packet. If a packet is small enough to fit in a single data cell, both the SOP flag 312 and the EOP flag 318 are set. In other words, a one-cell packet has both the SOP flag 312 and the EOP flag 318 set. The test flag 320 indicates whether a cell is a data cell or a test cell. Since the cell 300A is a data cell, the test flag 320 is not set (e.g., it is set to zero). However, for test cells, the test flag 320 is set (e.g., it is set to one). The RDOK flag 322 is set by the ingress module 106-1, if the egress module 108-1 on the same packet processor module can accept cells from (e.g., is not full) the switching fabric modules 130. The RDOK flag 322 is set during normal operation. The HI flag 324 is used in conjunction with the CEP field 310 to identify a set of egress ports for the cell 300A. In an embodiment, the CEP field 310 is a 4-byte bit field where each bit indicates an egress port. Since there are 32 bits in the 4-byte bit field, the CEP field 310 could be used to indicate up to 32 unique egress ports. However, in an embodiment with 64 unique egress ports, the HI bit may be used to distinguish between the 32 “low” egress ports and the 32 “high” egress ports. Thus, in this embodiment, the CEP field 310 and the HI bit, used together, identify up to 64 unique egress ports. In an embodiment, the CEP field 310 is set when sending the cell 300A from an ingress and replaced with other control information after the cell 300A is received at an egress such as the ingress from which the cell originated. In an embodiment, the row ID/continuation field 326 is a 2-bit rotating row identifier that is compared a 2-bit running counter (there is one per unicast egress reassembly queue) at the egress if the cell 300A is a unicast cell (e.g., the MC flag 314 is not set). The function of the row ID/continuation field 326 is discussed later with reference to FIG. 4G for unicast cells. The ECC field 328 is used for error checking and correction of portions of the cell. A detailed explanation of the ECC field 328 is not necessary for an understanding of the invention.
FIGS. 3B-3G are block diagrams of exemplary test cells for use with the system 100 (FIG. 1) in an embodiment of the invention. An additional header (not shown) similar to the additional header 306 (FIG. 3A) may be attached to a test cell, but a detailed explanation of the additional header is not necessary for an understanding of the invention. Fields not described with reference to each of the FIGS. 3B to 3G include ECC fields, reserved fields, and static fields (e.g., fields set to all ‘0’ or some other pattern). A detailed explanation of these fields has been omitted and is not necessary for an understanding of the invention.
FIG. 3B is a block diagram of an exemplary diagnostic cell 300B that is used to facilitate diagnosis of a path of an ingress-to-egress channel in the system 100 (FIG. 1) in an embodiment of the invention. The diagnostic cell 300B includes 16 4-byte words 332-1 to 332-16. Accordingly, the diagnostic cell 300B is the same size as the header 302 and payload 304 of the data cell 300A (FIG. 3A). The diagnostic cell 300B includes a header 334 that is similar to the header 302 (FIG. 3A), one or more 3-bit test cell type (TCT) fields 336 that identify the test cell type (e.g., for the diagnostic cell 300B the field is set to ‘000’), a series of diagnostic cell number fields 338-1 to 338-3 (collectively referred to as the diagnostic cell number field 338), and a diagnostic cell number reset (DR) field 340. The diagnostic cell number field 338 is used to keep count of the number of diagnostic cells sent over a period of time. The DR field is used to reset the diagnostic cell number field 338 to a reset value (e.g., zero). In an embodiment, the 4-byte words 332-9 to 332-16 are test data that is set by software. These fields are used to verify that data is properly received when the diagnostic cell 300B is forwarded from an ingress to an egress, as described later with reference to FIG. 4A.
FIG. 3C is a block diagram of an exemplary active fabric mask (AFM) cell 300C that is used to inform an egress module of an AFM change at an ingress module in the system 100 (FIG. 1) in an embodiment of the invention. The AFM cell 300C includes 16 4-byte words 342-1 to 342-16. Accordingly, the AFM cell 300C is the same size as the header 302 and payload 304 of the data cell 300A (FIG. 3A). The AFM cell 300C includes a header 344 that is similar to the header 302 (FIG. 3A), one or more 3-bit TCT fields 346 that identify the test cell type (e.g., for the AFM cell 300C the field is set to ‘001’), and a 4-bit AFM field 348 that identifies which switching fabric modules 130 (FIG. 1) are active and enabled for data transfer. In this example, the four bits of the AFM field 348 are respectively associated with four switching fabric modules 130. When a bit of the AFM field 348 is set, that indicates the corresponding switching fabric module is considered to be active (i.e., the switching fabric module is ready to forward data cells) and enabled to transfer data cells at the ingress. A use for the AFM cell 300C is discussed later with reference to FIGS. 4A, 4C, and 4D.
FIG. 3D is a block diagram of an exemplary heartbeat cell 300D that is used to periodically diagnose paths of an ingress-to-egress channel in the system 100 (FIG. 1) in an embodiment of the invention. The heartbeat cell 300D includes 16 4-byte words 352-1 to 352-16. Accordingly, the heartbeat cell 300D is the same size as the header 302 and payload 304 of the data cell 300A (FIG. 3A). The heartbeat cell 300D includes a header 354 that is similar to the header 302 (FIG. 3A), one or more 3-bit TCT fields 356 that identify the test cell type (e.g., for the heartbeat cell 300D the field is set to ‘010’), a 4-bit AFM field 358 that identifies which switching fabric modules 130 (FIG. 1) are currently active and enabled for data transfer, and a heartbeat sequence identifier field 352-9 that is used to keep track of heartbeat cells. The AFM field 358 is used for the purpose of checking, not setting, active switching fabric configurations; the AFM cell 300C (FIG. 3C) is used to facilitate changing the active switching fabric configurations. A use for the heartbeat cell 300D is discussed later with reference to FIG. 4B.
FIG. 3E is a block diagram of an exemplary flush cell 300E that is used to flush a path of an ingress-to-egress channel in the system 100 (FIG. 1) in an embodiment of the invention. The flush cell 300E includes 16 4-byte words 362-1 to 362-16. Accordingly, the flush cell 300E is the same size as the header 302 and payload 304 of the data cell 300A (FIG. 3A). The flush cell 300E includes a header 364 that is similar to the header 302 (FIG. 3A), one or more 3-bit TCT fields 366 that identify the test cell type (e.g., for the flush cell 300E the field is set to ‘100’), a field that differentiates flush cells from sync cells, flush vs. sync fields 367-1 to 367-N (collectively referred to as the flush vs. sync field 367), and a series of 11-bit tail pointer fields 368-1 to 368-4 (collectively referred to as the tail pointer field 368) that are set to a flush value (e.g., all zero). The tail pointer at a switching fabric is used to traverse a first-in-first-out queue (FIFO). When the tail pointer field 368 is used to set the tail pointer at the switching fabric to the flush value, the tail pointer is reset. In other words, the queue is emptied. A use for the flush cell 300E is discussed later with reference to FIGS. 4A, 4C, 4D, 4E, 4F, and 4G.
FIG. 3F is a block diagram of an exemplary sync request cell 300F that is used to request an ingress module generate a sync cell (see, e.g., FIG. 3G) in the system 100 (FIG. 1) in an embodiment of the invention. The sync request cell 300F includes 16 4-byte words 372-1 to 372-16. Accordingly, the sync request cell 300F is the same size as the header 302 and payload 304 of the data cell 300A (FIG. 3A). The sync request cell 300F includes a header 374 that is similar to the header 302 (FIG. 3A), one or more 3-bit TCT fields 376 that identify the test cell type (e.g., for the sync request cell 300F the field is set to ‘011’), and a 4-bit RMPRI field 378 that identifies one or more queues that are associated with either multicast or unicast cells and the priority of the one or more queues. In this example, the priority portion of the RMPRI field 378 is 3 bits long, which is sufficient to represent up to 8 priorities. A use for the sync request cell 300F is discussed later with reference to FIGS. 4F and 4G.
FIG. 3G is a block diagram of an exemplary sync cell 300G for use with the system 100 (FIG. 1) in an embodiment of the invention. The sync cell 300G includes 16 4-byte words 382-1 to 382-16. Accordingly, the sync cell 300G is the same size as the header 302 and payload 304 of the data cell 300A (FIG. 3A). The sync cell 300G includes a header 384 that is similar to the header 302 (FIG. 3A), one or more 3-bit TCT fields 386 that identify the test cell type (e.g., for the sync cell 300G the field is set to ‘101’), a field that differentiates flush cells from sync cells, flush vs. sync fields 398-1 to 398-4 (collectively referred to as the flush vs. sync field 398), a series of 11-bit tail pointer fields 388-1 to 388-4 (collectively referred to as the tail pointer field 388) that indicates the fabric queue tail pointer value that is expected by the ingress module that generated the sync cell 400G, an ignore color check flag 390, a sync column (SC) field 392, an AFM field 394 (for checking, not setting), and a color field 396. A use for the sync cell 300G is discussed later with reference to FIGS. 4D, 4F, and 4G.
The flowchart 400A continues at step 402 with flushing the switching fabrics. In an embodiment, the flushing includes flushing the disabled switching fabric and each switching fabric identified in the switching fabric configuration. FIG. 6A illustrates an exemplary flowchart 600A for flushing a FIFO of a switching fabric. First, the ingress waits for the switching fabric to drain at step 601. Waiting for the switching fabric to drain means waiting for a period of time while the switching fabric continues forwarding cells that the ingress previously sent to the switching fabric. In an embodiment, the AFM indicates switching fabrics that are enabled for sending data, but a lock mask prevents the ingress from sending data regardless of the setting of the AFM. In other words, an operational mask determined by ANDing the AFM and a lock mask determines whether the ingress may send data on a switching fabric. An arbitrary number of masks may be used to provide additional control over the operational mask. In this way, when a change in configuration occurs, such as the disabling of a switching fabric, the operational mask prevents the ingress from sending data over enabled switching fabrics until a lock between the ingress and egress is accomplished. At decision point 602 it is determined whether a timeout has occurred. A timeout is desirable because occasionally a switching fabric becomes “stuck” and does not drain completely. If a timeout has not occurred (602-N), then it is determined at decision point 603 whether the switching fabric is empty. If not, the ingress continues waiting for the switching fabric to drain at step 601. When either the ingress has waited for a predetermined period of time and a timeout occurs (602-Y) or the switching fabric becomes empty (603-Y), the ingress generates a flush cell, such as flush cell 300E (FIG. 3E), at step 604. The ingress sends the flush cell to the switching fabric at step 605. The flush cell includes a flush value, such as the value of the tail pointer field 368 (FIG. 3E). The switching fabric uses a tail pointer to access a FIFO for cells received from the ingress. After the switching fabric receives the flush cell at step 606, the switching fabric flushes the relevant switching fabric FIFO at step 607. To flush the FIFO, the switching fabric sets the tail pointer to the flush value of the flush cell. When the switching fabric sets the tail pointer to the flush value, the FIFO is treated as empty (i.e., the switching fabric FIFO is flushed). Since each flush cell targets a specific FIFO, flushing is selective. Selective flushing limits impact on other system resources.
Referring once again to FIG. 4A, it is determined at decision point 405 whether the path is OK. A path is “OK” if, for example, a path that includes the disabled fabric has a positive diagnosis. If not, the flowchart 400A ends without enabling the switching fabric. If the path is OK, then at step 406 the switching fabric configuration is changed to enable the one or more switching fabrics that were positively diagnosed for data transmission. Refer to step 401 for an example of how the switching fabric configuration is changed. At step 407, the switching fabrics are flushed (see, e.g., FIG. 6A). At step 408, the active switching fabrics are enabled (see, e.g., FIG. 6B). Then the flowchart 400A ends.
If the switching fabric is synchronized (644-Y), the switching fabric forwards the sync cell to an egress at step 651, the egress receives the sync cell at step 652, and at decision point 653 it is determined whether the egress is synchronized with the switching fabric. A color identifies each sync cell and a set of sync cells sent across different switching fabrics of an ingress-to-egress channel have the same color, such as found in the color field 396. Thus, the egress can distinguish between old and new sync cells and determine whether a sync cell has been lost. It should be noted that when a color sequence is starting or is restarted, the egress ignores the color. The egress determines whether to ignore color by checking a flag, such as the IC flag 390 (FIG. 3G). If the color of a sync cell does not match the color expected by the egress and the sync cell's ignore color bit is not set, then the egress is not synced. In addition to the color field in a sync cell, each sync cell also contains a sync column field. The sync column field should match the egress column pointer or else the ingress and the egress are not synced. If the egress is synchronized with the sync cell (and, accordingly, with the ingress), then the flowchart 600E ends. If not (653-N), then the egress reassembly queues are flushed at step 654. At step 655 the egress synchronizes its column pointer according to a sync column value, such as in the SC field 392 (FIG. 3G), of the sync cell. Then, at step 656, the egress sends its local ingress (the ingress on the same packet processor module as the egress) a sync request request. The sync request request includes information as to which egress reassembly queue is not synchronized (priority, unicast/multicast) and to which ingress the reassembly queue corresponds (CEP). In response to the sync request request, at step 657 the local ingress sends a sync request cell (or set of sync request cells) as per FIG. 3F to the egress specified by the CEP in the sync request request. The RMPRI field of the sync request cell is determined by the reassembly queue information provided in the sync request request. At step 658, the egress that is on the same packet processor module as the ingress that sent the original sync cell will receive the sync request cell. Since the sync request cell contains priority and unicast/multicast information of the out-of-sync reassembly queue, and the egress that received the sync request cell knows which ingress it came from and hence the egress it came from (same packet processor module), then the egress can identify which reassembly queue needs synchronization. At step 659, the egress passes this information to its local ingress (same packet processor module) via a sync request message, the ingress generates a sync cell targeting the reassembly queue requiring synchronization at step 641, and the flowchart 600E continues as previously described. In an alternative embodiment (not shown), egress reassembly queues that are not in sync do not send sync request requests after step 655, but go to ‘end’ after flushing reassembly queues and updating column pointers. This would typically happen after an egress is first brought out of reset. In an embodiment, software can initiate the generation of sync request cells at an ingress.
FIG. 4G depicts a flowchart 400G of a method for online unicast error detection and correction. The flowchart 400G starts at step 461 with including a row ID in a cell. In an embodiment, the row ID is included in both unicast data cells and unicast test cells. With respect to a data cell, such as the cell 300A (FIG. 3A), the row ID is included in, for example, the row field 326 (FIG. 3A). The row ID is not included in multicast cells because this form of error correction is not easily suited to multicast error correction. At decision point 462, it is determined whether the cell is a starting cell. In this case, “starting cell” refers to the cell that is striped across an arbitrary starting switching fabric. In an embodiment, the starting switching fabric is switching fabric 0 for unicast traffic. If the cell is a starting cell (462-Y), then the ingress increments a row ID counter at step 463 then sends the cell at step 464. If, on the other hand, the cell is not a starting cell (462-N), then the ingress sends the cell at step 464 with the current row ID counter. In this way, the starting cell and each subsequent cell striped across switching fabrics other than the starting switching fabric have the same row ID. It should be noted that switching fabrics may or may not be active for data transmission. In such cases, the ingress ignores the unused switching fabric, sends a cell on a next available switching fabric, and increments the row ID counter anyway.
FIGS. 5A-5E depict exemplary striped traffic consistent with traffic striped across the subsystem 200 (FIG. 2) in an embodiment of the invention. FIG. 5A is intended to illustrate changes in switching fabric configuration that result in the disabling and subsequent enabling of one of a plurality of switching fabrics. At time periods 0 to 6, snapshots 500A show traffic passing through each of four switching fabrics 0 to 3. At time 0, the switching fabrics respectively forward cells of packet “A”, A.0, A.1, A.2, and A.3. At time 1, the switching fabrics 0, 1, and 2 respectively forward the cells A.4, A.5, and A.6, but the switching fabric 3 is idle. The switching fabric 3 could be idle for a number of reasons, but for the purposes of this example, the switching fabric 3 is idle because it has been removed from the striping sequence at the ingress transmitting the cells of packet A. At time 2, the switching fabrics 0, 1, and 2 forward AFM cells that serve to inform the egress of the new striping sequence. The switching fabric 3, since it is no longer active, remains idle. At time 3, the switching fabrics 0, 1, and 2 respectively forward cells A.7, A.8, and A.9, while the switching fabric 3 remains idle. At time 4, the switching fabrics 0, 1, and 2 forward cells A.10, A.11, and A.12. The switching fabric 3 forwards an AFM cell. In this example, the AFM cell indicates that switching fabric 3 has been included in the striping sequence at the ingress. At time 5, the switching fabrics 0, 1, and 2 also forward the AFM. In this example, the AFM indicates that all of the switching fabrics are now active. Traffic then resumes across all switching fabrics starting with the switching fabric 3, which forwards cell A.13. At time 6, the switching fabrics respectively forward the cells A.14, A.15, A.16, and A.17.
FIG. 5B is intended to illustrate the forwarding of test cells across switching fabrics on a unicast path. At time periods 0 to 3, snapshots 500B show traffic passing through each of four switching fabrics 0 to 3. At time 0, the switching fabrics respectively forward cells of packet “A”, A.0, A.1, A.2, and A.3. For the purposes of this example, A.9 is the last cell of packet A. At time 1, the switching fabrics 0, 1, and 2 respectively forward the cells A.4, A.5, and A.6, but the switching fabric 3 is forwards a test cell. For the purposes of this example, the test cell is ready for sending after a cell is sent on switching fabric 2. Accordingly, the test cell is forwarded on switching fabric 3. Some test cells, such as sync cells, come in sets. A set of test cells is as large as the number of switching fabrics that are active for testing. In this example, four switching fabrics are active for testing; so the test cells are sent on each of the four switching fabrics in succession. Accordingly, at time 2, the switching fabrics 0, 1, and 2 forward test cells and switching fabric 3 resumes forwarding cells of packet A with cell A.7. At time 3, the switching fabrics 0 and 1 forward cells of packet A, A.8 and A.9. However, the switching fabrics 2 and 3 forward cells of packet B, B.0 and B.1. In an embodiment, the cells of different packets are treated the same for the purpose of sending across switching fabrics. Unlike test cells sent on a unicast path, such as is shown in FIG. 5B, test cells sent on a multicast path must begin on a predetermined starting switching fabric.
FIG. 5C is intended to illustrate the forwarding of test cells across switching fabrics on a multicast path. For the purposes of FIG. 5C, the starting switching fabric is switching fabric 0. At time periods 0 to 3, snapshots 500C show traffic passing through each of four switching fabrics 0 to 3. At time 0, the switching fabrics respectively forward cells of packet “A”, A.0, A.1, A.2, and A.3. At time 1, the switching fabrics 0, 1, and 2 respectively forward the cells A.4, A.5, and A.6, but the switching fabric 3 is idle. For the purposes of this example, A.6 is the last cell of packet A. Also for the purposes of this example, a test cell is ready for sending after a cell is sent on switching fabric 2. However, since the starting switching fabric for this multicast path is switching fabric 0, the first test cell must be forwarded on switching fabric 0, not switching fabric 3. A discussion of the rule requiring starting at the starting fabric, and when the rule can be broken, is discussed in co-pending patent application serial number (TBD), entitled “OPTIMAL LOAD BALANCING ACROSS MULTIPLE SWITCHING FABRICS”, which has been incorporated by reference. Furthermore, for the purposes of this example, a cell from a different packet is ready for sending after a cell is sent on switching fabric 2. However, since the starting switching fabric for this multicast path is switching fabric 0, the cells of the different packet must be forwarded starting on switching fabric 0, too. Therefore, even though A.6 is the last cell of packet A, the switching fabric 3 is idle. It should be noted if A.7 were the last cell of packet A, then switching fabric 3 would forward cell A.7 (because A.7 is not the first cell of a packet) instead of remaining idle. In any case, at time 2, the switching fabrics respectively forward the test cells. Then, at time 3, the switching fabrics respectively forward the cells B.0, B.1, B.2, and B.3.
FIG. 5D is intended to illustrate an error in sending test cells across switching fabrics. At time periods 0 to 3, snapshots 500D show traffic passing through each of four switching fabrics 0 to 3. At time 0, the switching fabrics respectively forward cells of packet “A”, A.0, A.1, A.2, and A.3. At time 1, the switching fabrics 0 and 2 respectively forward the cells A.4 and A.6, but the switching fabrics 1 and 3 forward test cells; and at time 2, the switching fabrics 0 and 2 forward test cells while the switching fabrics 1 and 3 are idle. In this example, the test cells should be forwarded in succession when the system is working properly. As is apparent in this example, the test cells are interspersed with data cells at times 1 and 2. Accordingly, the system should signal an error and/or attempt to resynchronize in this case.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS6272107 *May 12, 1998Aug 7, 20013Com CorporationMethod of path restoration in an ATM network utilizing point to point switched virtual circuitsUS7020393 *Dec 12, 2001Mar 28, 2006Alcatel Canada Inc.Method of synchronizing parallel optical links between communications componentsUS7058010 *Mar 29, 2001Jun 6, 2006Lucent Technologies Inc.Controlled switchover of unicast and multicast data flows in a packet based switching systemUS20020089977May 15, 2001Jul 11, 2002Andrew ChangNetwork switch cross pointUS20030117961 *Dec 26, 2001Jun 26, 2003Chuah John Tiong-HengMethod and system for isolation of a fault location in a communications device* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS8156493 *Apr 12, 2006Apr 10, 2012The Mathworks, Inc.Exception handling in a concurrent computing processUS8209419Jul 19, 2007Jun 26, 2012The Mathworks, Inc.Exception handling in a concurrent computing processUS8863130Jun 26, 2012Oct 14, 2014The Mathworks, Inc.Exception handling in a concurrent computing process* Cited by examinerClassifications U.S. Classification370/244International ClassificationH04J3/14, H04Q3/545Cooperative ClassificationH04Q2213/13109, H04Q3/54591, H04Q2213/1316, H04Q2213/1304, H04Q2213/13162, H04Q2213/1302European ClassificationH04Q3/545T2Legal EventsDateCodeEventDescriptionJun 25, 2003ASAssignmentOwner name: RIVERSTONE NETWORKS, INC., CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MATHEWS, GREGORY S.;ANDERSON, ERIC;FEROLITO, PHILIP;AND OTHERS;REEL/FRAME:014207/0844Effective date: 20030604Dec 1, 2010ASAssignmentOwner name: LUCENT TECHNOLOGIES INC., NEW JERSEYFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RIVERSTONE NETWORKS, INC.;REEL/FRAME:025404/0434Effective date: 20060427Effective date: 20081101Free format text: MERGER;ASSIGNOR:LUCENT TECHNOLOGIES INC.;REEL/FRAME:025404/0466Owner name: ALCATEL-LUCENT USA INC., NEW JERSEYJul 17, 2014FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services