This invention relates generally to multi-stage switching fabrics and, more particularly, to forwarding frames within multi-stage switching fabrics.
Switching devices are typically data link layer devices that enable multiple network devices to communicate with each other or enable physical network (e.g., local area network (LAN) or wide area network (WAN)) segments to be interconnected into a single larger network. In the most general sense, switching devices transport data in the form of frames between input/output (I/O) ports. A frame is a logical grouping of information sent as a data link layer unit over a transmission medium. Each frame typically includes data payload encapsulated between header and trailer information. Terms like cell, datagram, message, packet, and segment are also used to describe logical information groupings at various layers of the OSI reference model and in various technology circles. As used herein, the term “frame” should be understood in this broadest sense, and can be defined to encompass other terms such as cell, datagram, message, packet, segment, etc.
Switching devices often employ switching fabrics that have multiple I/O ports coupled to each other. Users typically require that each switching device operate as quickly as possible in order to maintain a high data throughput rate. Unfortunately, limitations within the switching device hardware can impair the ability of the switching device to operate as quickly as possible. For example, changes in configuration of the switching device can lead to there being an inability to completely specify each destination port using predefined internal addressing information, causing the egress line card to either flood the frame through all output ports (including ones that did not actually need to output that frame, which may adversely affect other traffic being output from those output ports) or perform an additional lookup for the frames at the output ports, leading to a decrease in performance.
A more complete understanding of the present invention may be acquired by referring to the following description and the accompanying drawings, in which like reference numbers indicate like features.
While the invention is susceptible to various modifications and alternative forms, specific embodiments of the invention are provided as examples in the drawings and detailed description. It should be understood that the drawings and detailed description are not intended to limit the invention to the particular form disclosed. Instead, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
Overview
A switching device that includes a multiple-stage switching fabric generates an internal header to use when forwarding a frame through the switching fabric. This internal header can include several fields, one of which is used to select a fabric point of exit for the frame in one stage of the switching fabric, and another of which is used to select a fabric point of exit for the frame in a different stage of the switching fabric. In some embodiments, the different headers are used in this manner only if the frame is a special type of frame; otherwise (i.e., if that frame is not the special type of frame), a single field is used to select the fabric point of exit for all of the stages of the switching fabric. The value of the field of the internal header that is used to select the fabric point of exit for a final stage of the switching fabric may also be selectively masked, as indicated by yet another field of the internal header.
Example Embodiments
A switching device can support one or more of a variety of different communication protocols that enable data communication between network devices. Switching device 100 can be included in one or more storage, local, and/or wide area networks. Switching device 100 and similar switching devices can be used in networks implemented using various topologies, communication protocols, and physical links (e.g., wireless links, coaxial cables, and the like).
Switching device 100 includes m line cards (where m is an integer greater than or equal to two), including line cards 110(1) and 110((m)), which are coupled by a backplane 120. Each line card includes n ports, where n is an integer greater than or equal to two (furthermore, in some embodiments, the number of ports per line card can vary). Line card 110(1) includes ports 112(1)(1)-112(1)((n)), and line card 110((m)) includes ports 112((m))(1)-112((m))((n)). Each port is a device (e.g., implemented using one or more application specific integrated circuits (ASICs) or other technology) that is configured to send and receive frames via a network.
A port can be coupled to another device (e.g., a host or server computing device, another switching device, or the like) that generates and/or consumes frames. For example, a port can be coupled to another network device such as a router, switch, bridge, gateway, or the like, or to an end device, host device, or client device (e.g., such as a personal computer).
The line cards and the backplane each implement one stage of the switching fabric. Here, each stage of the switching fabric can be implemented in one or more devices (e.g., ASICs or other appropriate technology). Line card 110(1) implements switching fabric stage 114(1), and line card 110((m)) similarly implements switching fabric stage 114((m)). Likewise, backplane 120 implements switching fabric stage components 124(1)-124((n)). It is noted that while this example shows the same number of components in each line card, other embodiments may vary the number of switching fabric stage components implemented on each line card. It is also noted that, while this example shows three switching fabric stages (as explained in more detail below), other embodiments may support additional numbers of switching fabric stages.
When a frame enters switching device 100 by being received at a port (the receiving port at which a frame enters the switching device is referred to as the ingress port), information included in that frame is used to convey that frame through the switching fabric to the appropriate output port (referred to as the egress port) or ports coupled to provide the frame to its destination (e.g., by being directly coupled to the destination device or by being coupled to another switching device along a route leading to the destination device). For example, if a frame is received via port 112(1)(1), that frame will be processed to determine which port or ports the frame should be output from to reach its destination. If the frame's destination only includes ports within the same line card 110(1), that frame can simply be passed to the appropriate port via the local switching fabric stage, without being conveyed off of the ingress line card.
If the appropriate egress port(s) are not located in the same line card as the ingress port that received the frame, the frame will need to be forwarded from line card 110(1) (the ingress line card) to the appropriate egress line card (line card 110((m)) in this example) via backplane 120. In such a situation, the frame will need to pass through three switching fabric stages: an ingress stage on the ingress line card 110(1), a backplane stage on the backplane 120, and an egress stage on the egress line card 110((m)). (It is noted that the switching fabric stage components on line cards can act as both ingress and egress switching fabric stages in some embodiments. Alternatively, separate switching fabric stages for ingress and egress can be implemented on both line cards.)
To enable the frame to be conveyed by each switching fabric stage that will handle the frame, the ingress line card 110(1) generates information (e.g., based upon the frame's destination address and/or other characteristics of the frame such as class of service, virtual local area network (VLAN), ingress port identifier, and the like) and appends an internal header containing the information to the frame, as shown in
The FPOE refers to the fabric stage port (not to be confused with the ports of the switching device that can actually be coupled to other network devices) from which the frame should exit a particular fabric stage, based upon the next stage component and/or egress port that the particular fabric stage port is coupled to. For example, the FPOE for the frame can indicate that the frame should exit switching fabric stage 114(1) via the fabric stage port coupled to switching fabric stage component 124(2). Similarly, the FPOE for the frame can indicate that the frame should exit switching fabric stage 124(2) via the fabric stage port coupled to line card 110((m)). In one embodiment, the FPOE field contains a value that directly identifies the FPOE(s). In other embodiments, the FPOE field indirectly identifies the FPOE(s). In such embodiments, the value of the FPOE field addresses a location within a FPOE memory, which stores the information identifying the FPOE(s).
In some situations, a manufacturer may increase the number of fabric stage components beyond the addressing capacity of the FPOE field and/or beyond the amount of memory available to store FPOEs in a corresponding memory. For example, due to limitations in the amount of memory, it may not be possibly to fully specify all FPOEs for all of the switching fabric stages for at least some types of frames. In one such situation, it may not be possible to provide a FPOE value that can specify the final FPOE for the last switching fabric stage to convey a multicast frame (i.e., a frame being sent to a multicast destination, which specifies more than one destination). As a result, the egress line card may simply have to flood the frame to all of the possible FPOEs of the last switching fabric stage, which in turn causes the frame to be included in each flow that is to be provided to one of the egress ports. This can introduce large inefficiencies into the operation of the switching device, which will either unnecessarily output the frame from all possible ports on the egress line card or expend valuable time and/or processing resources to remove the frame from egress flows in which the frame has unnecessarily been included.
In order to reduce or even avoid this inefficiency, the switching device of
As an example of how multiple internal fabric header fields can be used to specify FPOEs, in some embodiments, switching device 100 uses the FPOE field (FPOE 216 of
Switching device 100 can, in some embodiments, be configured to use different internal frame header fields to specify FPOE(s) for different switching stages for all frames. In many other embodiments, however, switching device 100 can use multiple fields in this manner for only certain types of frames. For example, in one embodiment, multiple fields are used for FPOE addressing only for multicast frames. In another embodiment, multiple fields can be used only for frames being conveyed in certain network layers and/or having certain priorities. Many other ways of distinguishing among frames, such that only certain frames use multiple internal frame header fields for FPOE addressing, are possible.
As described above, in at least some embodiments, switching device 100 is effectively reusing an already-defined internal frame header field for a different purpose than it was originally defined. For example, as described above, the DI field can be reused to identify FPOE(s). In situations in which this reuse occurs for only certain types of frames, some frames (handled normally) within the switching device can use the reused field normally (e.g., such frames would use the DI field to carry DI information), while other frames within the switching device can use that field (e.g., the DI field) to carry the FPOE information.
As noted above, in one embodiment, switching device 100 uses the DI field to store information indicating the FPOE(s) for the final switching fabric stage. As an example, assume the DI field has at least 16 bits and is thus capable of representing a 64K address space. This space is mapped into two regions labeled L2 and L3. In this example, L2 entries occupy two (2) lines in the DI space. In contrast, L3 entries occupy one (1) line in the DI space. The L2 and L3 ranges in the DI space can be of any size and in either order (i.e., the L2 range can be above or below the L3 range), so long as the L2 and L3 ranges do not overlap.
In this example, the FPOE field is 12 bits in size and the memory available to store FPOE information is 4K in size. DI addresses (addresses specified by the DI field) are mapped to FPOE addresses (addresses of the 4K memory available to store FPOE information) based on each of the DI addresses' offset into the range (L2 or L3) those DI addresses belong to. Within the FPOE memory, the size of the L3 range is 2^N. A pair of adjacent default indexes can be present in the FPOE memory for situations in which the DI address misses (e.g., fails to properly map into the FPOE address space, as shown in the algorithm below).
In this example, the value in the DI field is mapped into the address space represented by the FPOE field according to the following algorithm. This algorithm can be implemented by one or more switching fabric stages implemented on a line card and/or backplane.
As shown, the algorithm first selects the portion of the DI field to use (in this example, the DI field can be greater than the number of bits used to address the DI address space). The, the algorithm determines whether the address specified by those bits is within the L3 range by seeing if the address is greater than or equal to the lowest address in the L3 range (L3_range_lo) and less than or equal to the highest address in the L3 range (L3_range_hi). If so, the algorithm generates an index by getting the offset of the address within the L3 range (by subtracting the lowest address in the L3 range from the address) and discarding the upper bits of the address. Thus, in this example, a DI address of (L3_range_lo+10) would address location 10 in the FPOE memory.
If the address is not within the L3 range, the algorithm checks to see if the address is within the L2 range by virtue of being greater than or equal to the lowest address in the L2 range (L2_range_lo) and less than or equal to the highest address in the L2 range (L2_range_hi). In this example, L2 addresses sit above L3 addresses in the L3 memory, so if the offset is not enough to rise above the highest L3 address (as determined by comparing the offset, which is obtained by subtracting the lowest address in the L2 range from the address, to the size of the L3 range (2^N) in the memory), then the lowest L2 address is added to the offset. If the address cannot be properly mapped, one of several default indexes is selected by the algorithm.
The above algorithm provides just one example of how multiple internal frame header fields can be used to specify FPOEs. Many other variations are possible, including those in which the values some or all of the fields directly specify the FPOEs, those in which a larger address space is not mapped to a smaller memory, and the like.
In addition to using multiple fields of the internal frame header to specify FPOEs for different switching fabric stages, the switching device 100 can also use another field of the internal frame header to indicate whether an optional mask (e.g., a value that is combined with the value to be masked using a logical operation such as AND) needs to be applied to information indicating or identifying the FPOEs. For example, switching device 100 can maintain a mask value in a register and components for applying the mask value to another value. The ingress line card can specify a value of another internal frame header field that indicates whether the mask value in the register should be applied to FPOE information (e.g., the information obtained from an FPOE memory and/or the value of an internal frame header field that identifies or otherwise indicates one or more FPOEs).
In one embodiment, switching device 100 can selectively use the CCC field (CCC 212 of
As noted above, the internal frame header can be generated by the ingress line card in response to receipt of the frame by an ingress port. In many embodiments, each line card includes a forwarding engine (not shown in
Each port can be implemented as a combination of a port processor (the actual interface to the network) and a port processor controller that controls the port processor. Such a port processor controller can perform initial processing on frames (e.g., such as sending header information from the frame to a forwarding engine so that an appropriate internal frame header can be generated, removing internal frame headers from frames being output from switching device 100, and the like).
The method begins at 305, when an internal header is appended to the frame. As noted above, this operation can be performed by a forwarding engine on the ingress line card. The internal header includes several fields, at least two of which store information indicative of FPOEs from switching fabric stages that will process the frame.
As indicated at 310 and 315, if the current line card handling the frame is not the egress line card (and thus is not implementing the egress switching fabric stage), the switching fabric stage within that line card will use a first portion (e.g., a first field) of the internal header to select the switching fabric point(s) of exit for that frame. For example, the switching fabric stage can retrieve the value in the FPOE field of the internal frame header and use that value as index into an FPOE memory. The information stored at the location identified by the FPOE field identifies the FPOEs for the switching fabric stage.
If the current line card is the egress line card (and thus is implementing the egress switching fabric stage), a determination is made as to whether the frame is the type of frame to which special handling (involving multiple fields that specify FPOEs) applies, as shown at 320. This operation can be performed by the egress switching fabric stage checking one or more characteristics of the frame. For example, the egress switching fabric stage can check to see if the frame is a multicast frame, based upon information within the internal frame header and/or information within the frame's header.
If the frame is the special type of frame to which special handling applies, the egress switching fabric stage will use a second portion (e.g., a second field) of the internal frame header to select the fabric point(s) of exit for the frame, as indicated at 325. The second portion is different than the first portion (e.g., do to being a different field entirely or a concatenation of a different field with all or part of the first portion). In one embodiment, the first portion is the FPOE field and the second portion is the DI field. In this embodiment, the switching fabric stage can obtain the value of the DI field, map the value into an FPOE address space (e.g., using the algorithm described above) if needed, and retrieve the information addressed by the value from an FPOE memory.
As noted above, one or more switching fabric stages can also selectively apply a mask to information that identifies or indicates the FPOEs. For example, if only the egress switching fabric stage uses the mask, operation 325 can additional involve checking to see if the internal frame header field related to masking indicates that a mask should be applied and, if so, applying the mask to the appropriate value (e.g., the information obtained from the FPOE memory).
If the frame is not the special type of frame, the frame can be processed by the egress switching fabric stage using the same portion (the first portion) of the internal frame header that was used to select the FPOEs in prior switching fabric stages, as indicated at 330.
Memory 406 stores program instructions executable to implement all or part of a forwarding engine 450, a switching fabric stage controller 452, a mask value 456, and/or an FPOE memory 454. (Alternatively, one or more of these components can be implemented in hardware). The forwarding engine 450 can be configured to generate an internal frame header for a frame 425 based on the frame's characteristics. For at least some frames, the forwarding engine can generate internal frame headers in which more than one field contains a value indicative of the FPOEs for the frame.
Switching fabric stage controller 452 can be configured to access an internal frame header associated with frame 425 and to use one or more fields within that internal frame header to select the FPOEs to which the frame should be sent via a switching fabric stage. Switching fabric stage controller 452 can, based upon the switching fabric stage controlled by the switching fabric stage controller 452 and/or the type of frame 425, select among several different fields of the internal frame header for a value to use in identifying the FPOEs.
FPOE memory 454 can store information identifying one or more FPOEs at each addressable location within FPOE memory 454. A switching fabric stage controller can obtain the address of a location within FPOE memory 454 from one or more fields of a frame's internal frame header. Additionally, a switching fabric stage controller can determine whether to apply the mask value 456 to the information obtained from that location (or to any other value used to select the FPOEs) based upon information in yet another field of the frame's internal frame header.
The program instructions and/or data executable to implement forwarding engine 450 and/or switching fabric stage controller 452 can be stored on various computer readable storage media such as a memory (e.g., RAM (Random Access Memory)). In some embodiments, such software is stored on a computer readable storage medium such as a CD (Compact Disc), DVD (Digital Versatile Disc), hard disk, optical disk, tape device, floppy disk, and the like). In order be executed, the software is loaded into memory from another computer readable storage medium. The instructions and/or data can also be transferred to a computing device for storage in memory via a network such as the Internet or upon a carrier medium. In some embodiments, the instructions and/or data are conveyed using a carrier medium such as a network and/or a wireless link upon which signals such as electrical, electromagnetic, or digital signals.
While
Although the present invention has been described with respect to specific embodiments thereof, various changes and modifications may be suggested to one skilled in the art. It is intended such changes and modifications fall within the scope of the appended claims.
Number | Name | Date | Kind |
---|---|---|---|
5430716 | Pawelski | Jul 1995 | A |
5537403 | Cloonan et al. | Jul 1996 | A |
5544160 | Cloonan et al. | Aug 1996 | A |
5724352 | Cloonan et al. | Mar 1998 | A |
6246692 | Dai et al. | Jun 2001 | B1 |
6658016 | Dai et al. | Dec 2003 | B1 |
6721316 | Epps et al. | Apr 2004 | B1 |
6731644 | Epps et al. | May 2004 | B1 |
6778546 | Epps et al. | Aug 2004 | B1 |
6813243 | Epps et al. | Nov 2004 | B1 |
6977930 | Epps et al. | Dec 2005 | B1 |
6980552 | Belz et al. | Dec 2005 | B1 |
7095744 | Iny | Aug 2006 | B2 |
7103039 | Rose | Sep 2006 | B1 |
7103059 | Li et al. | Sep 2006 | B2 |
7110671 | Islam | Sep 2006 | B1 |
7177276 | Epps et al. | Feb 2007 | B1 |
7184403 | Morishige et al. | Feb 2007 | B1 |
7209657 | Islam | Apr 2007 | B1 |
7215639 | De Maria et al. | May 2007 | B2 |
7242686 | Dougherty et al. | Jul 2007 | B1 |
7245582 | Roberts et al. | Jul 2007 | B1 |
7260655 | Islam | Aug 2007 | B1 |
7263288 | Islam | Aug 2007 | B1 |
7283547 | Hook et al. | Oct 2007 | B1 |
7283558 | Ferolito | Oct 2007 | B2 |
7305186 | Islam | Dec 2007 | B2 |
7342922 | Vanesko | Mar 2008 | B1 |
7352765 | Dai et al. | Apr 2008 | B2 |
7366412 | Beshai | Apr 2008 | B2 |
7525995 | Iny | Apr 2009 | B2 |
7554907 | Epps et al. | Jun 2009 | B1 |
7590102 | Varma | Sep 2009 | B2 |
7643486 | Belz et al. | Jan 2010 | B2 |
7792027 | Tatar et al. | Sep 2010 | B2 |
7809009 | Tatar et al. | Oct 2010 | B2 |
7864791 | Tatar et al. | Jan 2011 | B2 |
8018937 | Epps et al. | Sep 2011 | B2 |
8254390 | Hall et al. | Aug 2012 | B2 |
8547971 | Mizrahi | Oct 2013 | B1 |
8571024 | Tatar et al. | Oct 2013 | B2 |
8571031 | Davies et al. | Oct 2013 | B2 |
8665875 | Epps et al. | Mar 2014 | B2 |
20020031124 | Li | Mar 2002 | A1 |
20020061030 | Iny | May 2002 | A1 |
20030112797 | Li et al. | Jun 2003 | A1 |
20030223420 | Ferolito | Dec 2003 | A1 |
20040091264 | Beshai | May 2004 | A1 |
20040100954 | Dai et al. | May 2004 | A1 |
20050174940 | Iny | Aug 2005 | A1 |
20050226148 | Assarpour | Oct 2005 | A1 |
20060039374 | Belz et al. | Feb 2006 | A1 |
20060050690 | Epps et al. | Mar 2006 | A1 |
20060067315 | Tan et al. | Mar 2006 | A1 |
20070036546 | Islam | Feb 2007 | A1 |
20070067487 | Freebairn et al. | Mar 2007 | A1 |
20070195761 | Tatar et al. | Aug 2007 | A1 |
20070195773 | Tatar et al. | Aug 2007 | A1 |
20070195777 | Tatar et al. | Aug 2007 | A1 |
20070195778 | Tatar et al. | Aug 2007 | A1 |
20080075460 | Islam | Mar 2008 | A1 |
20080117913 | Tatar et al. | May 2008 | A1 |
20080267204 | Hall et al. | Oct 2008 | A1 |
20100272123 | Peterson | Oct 2010 | A1 |
20110064084 | Tatar et al. | Mar 2011 | A1 |
20120294305 | Rose et al. | Nov 2012 | A1 |
20120314707 | Epps et al. | Dec 2012 | A1 |
20140010536 | Shields et al. | Jan 2014 | A1 |
Number | Date | Country | |
---|---|---|---|
20120294305 A1 | Nov 2012 | US |