1 / 7

Radisys 7010 NPU Routing for Shared Metarouter Cards

Radisys 7010 NPU Routing for Shared Metarouter Cards. David M. Zar dzar@wustl.edu http://www.arl.wustl.edu/arl. Radisys 7010 Shared Metarouter Card. Physical Problem: We wish to route packets coming into a metarouter (MR) card to the NPU where the MR lives.

rooney-burt
Download Presentation

Radisys 7010 NPU Routing for Shared Metarouter Cards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Radisys 7010 NPU Routing for Shared Metarouter Cards David M. Zardzar@wustl.edu http://www.arl.wustl.edu/arl

  2. Radisys 7010 Shared Metarouter Card • Physical Problem: We wish to route packets coming into a metarouter (MR) card to the NPU where the MR lives. • Logical Problem: In the general case, where packets are arriving over the fabric switch on a 10 Gb/s link to the FIC, we cannot inspect packet data to route packets based on VLAN (or anything else).

  3. Radisys 2210 ATCA10 GE Switch Fabric 10 GE Fabric 10 GE SPI Channel 0 SPI Channel 1 The FIC • It has been reported that the FIC has an Intel IXF18203 Ethernet MAC to SPI-4 device on it.

  4. SPI Channel 0 NPUA NPUB SPI Channel 1 The FIC Continued • Now each channel can be routed through the SPI-4 switch to the proper NPU.

  5. Addressing MR/NPUs • To take advantage of this scheme: • each MR board must be connected to both switches in order to use both NPUs. • There is no failover for if one switch goes down, there is no way to get packets to the NPU accessed by that switch • The MAC address of one of the IXF18203 MAC devices is the logical MAC address of the NPU.

  6. Lookup Scheme • Packets arriving at the LC need to know where to go: • When a lookup is done to determine which MR is the destination, the logical MAC address of that MR needs to be inserted into the Enet header (no different than before except there are two MAC addresses per –shared- MR card), and • The SPI-4 channel number that is associated with that MAC address is sent to the TX block so that it can send the packet to the correct switch that can “see” this MAC address. • The “reverse” path works the same way: • When a lookup is done to send data from a MR to somewhere else, if that somewhere is another MR, it needs to know the logical MAC address of that MR and insert that into the Enet header. • At the same lookup, the SPI-4 channel number to send out on is also extracted and passed to the transmit block so it is transmitted on the correct channel to reach a switch that can “see” the specified MAC address. • If the destination is an LC, we could use either channel number as its SPI-4 switch would be configured to send all traffic to one NPU (the ingress NPU). If we keep the same channel as the incoming packet, however, then we know it will go out through the same switch that sent the packet to the MR.

  7. Future Scheme • Radisys has mentioned that the next version of the dual NPU blade will have the FIC on the board in the form of an FPGA that we will be able to reprogram. • We could then inspect the packets for VLAN tag to determine which SPI-4 channel to use. • We could have full failover, again, as all traffic could go to either switch and still be routed to the correct NPU through the FPGA lookup. • The timing of this new board is “sometime in 2007.”

More Related