Design of a Diversified Router: Project Assignments and Status Updates John DeHart jdd@arl.wustl.edu http://www.arl.wustl.edu/arl

People Dave Zar Mike Wilson Sailesh Kumar Amy Freestone Fred Kuhns Brandon Heller John DeHart Jing Lu Eric Lee Available for consultation: Ben Wun Haoyu Song Charlie Wiseman

Project Assignments Rx (LC and NPE) : Dave Tx (LC and NPE) : Dave Names in parentheses are staff who are to stay in touch with the work on that block to give us continuity after the student finishes work on the project, graduates or moves on to something else. Rx (LC and NPE) : Dave Tx (LC and NPE) : Dave QM/Scheduler (LC and NPE) : Sailesh and Amy (FredK, John) Lookup (LC and NPE) : John Parse (NPE: IPv4 and MPLS) : Brandon and Jing (John) Hdr Format (NPE: IPv4 and MPLS) : Jing and Brandon (John) Jing, Brandon and John will discuss how to divide up Parse and Hdr Format blocks: Brandon do both for IPv4 and Jing do both for MPLS or Brandon do Parse for both IPv4 and MPLS and Jing do Hdr Format for both IPv4 and MPLS. or … Hdr Format (LC) : Dave KeyExtractor (LC) : Mike (John) Loopback Block (If needed for Nov.) : John Control Plane : FredK + others as needed As we get a better sense of what needs to be done on the control side people who are working on individual blocks may work on the corresponding parts of the control infrastructure. Miscellaneous HW Details : Dave Blocks not needed for November 2006 Demo: RateMonitor (LC): Not needed by November Demo Demux (NPE): Not needed by November Demo

4/25/06 Update On 4/25/06, JDD had meetings with each person or group working on blocks in the designs (except Hdr Format on LC – Dave): Rx/Tx: Dave QM: Amy and Sailesh (with FredK) Parse and Hdr Format (MR): Jing and Brandon Key Extract: Mike Major Issues raised or outstanding: Having two TX blocks, one on each NP in a single blade trying to send to the same physical interface. How is flow control and rate control handled between the two? Handling of Flow Control between Tx and QM How does TX know that a Physical Interface on the RTM is overloaded? Can we modify the way the existing Tx indicates flow control to QM? GM Filter handling in Lookup for MRs TCAM Mask Registers will be a scarce resource for this, especially if we try to support general Transport Port ranges in GM-like keys. Per port scheduling structure for QM/Scheduler. Per Port rate control in QM/Scheduler Per Port flow control in QM/Scheduler Dequeue interrupted by flow control or rate control?

4/25/06 Update QM/Scheduler Status: Amy Sailesh Scheduling data structure block and macros Sailesh Q_Structures Data Structures and macros CAM Q-Array Q_Length Data Structure Q_Length Quantum Threshold Overall Control code Enqueue phases Dequeue phases “Project” management Separate Scheduling structure for each Physical Port We are looking at the implications of having a separate scheduling structure for each port. The impact on Local Memory usage is important. There are only 640 32-bit words of local memory. To keep a head and tail segment in Local memory for each of 10 ports will almost certainly cause us to have to use two instances of the QM/Scheduler block. The current plan is to split them based on Physical Interface in the same way that the TX block is split. This will also cause us to move the helper block that was between QM and TX and put it in front of QM to do the demux Per Physical Port Rate Control We are looking into implementing a token bucket scheme to control the rate of data sent to each physical interface. Per Physical Port Flow Control TX provides some flow control information to the QM/Scheduler. Implications of Port Rate Control and Port Flow Control It is possible that Dequeue will have to stop sending for a particular queue while it still has packets to send and before it has consumed its credits. Because of this we will need to be able to leave something on the head of the list for that Port so that it gets serviced first in the next iteration for that Port. This may also cause the head segment to not always be full. The implications of all of this are being considered.

4/25/06 Update MR Parse and MR Hdr Format Status: Implementing two MRs: IPv4 MPLS We’ll concentrate on the IPv4 MR first Once that is done we will work on the MPLS Jing and Brandon will work in parallel on the IPv4 MR, one doing the Parse block and one doing the Hdr Format block. Once IPv4 is done, the current plan is that they will switch roles and Jing will work on the MPLS Parse block and Brandon will work on the MPLS Hdr Format block. The idea of this split and switching of roles is that each will be familiar with Parse and Hdr Format block code and each will gain more experience in MR development. Each should gain insight into what is needed by an MR developer for our work on a shared NP design/implementation later. Division of Labor Jing IPv4 Hdr Format Block Brandon IPv4 Parse IPv4 Parse Block Brandon has a first implementation in C of the Parse block and is now going to be working on a framework to put around it to allow him to test it. Jing understands what the Hdr Format Block needs to do and will be working on pseudo code for it.

4/25/06 Update LC Key Extractor Block Status: Mike understands what the Key Extractor Block needs to do in each direction. The Ingress and Egress versions appear to be significantly different because of the frame header formats and the key formats. Mike will be working on pseudo code for each version and detailing the DRAM accesses needed to give us some scope on how many parallel threads we will need to keep up with line rate.

4/25/06 Update Rx/Tx Block Status: Dave is investigating the TX Flow control issues. How does the current TX Block communicate flow control information to the Scheduler? How easy will it be to change? What will happen when we run two MRs, one on each of the NPs on a single blade and each MR has a TX block sending traffic to the same Physical Interface on that blades RTM? Should each MR get half of each physical interface’s bandwidth? If so, how is that managed? Our current focus is on the 10x1 Gb/sec TX Block. In the November demo we will not have a need for the 1x10 Gb/sec TX Module since both blades will be using an RTM with 10 1Gb/sec physical interfaces.

4/25/06 Update LC Hdr Format Block Status: No status update.

4/25/06 Update Lookup Block Status: JohnD has begun looking at the TCAM and how it might be used for the Lookup Blocks. There are three Lookup Blocks that we need: LC-RX LC-TX NPE The basic structure of each of the Lookup Blocks should be very similar, but the Keys and Results for each will be quite different. As we learn some more about the TCAM and how we want to use it we will know more about how much code can be shared between the three blocks. One item that might be a significant issue is how GM-like filters might be used with the TCAM. The TCAM supports a fixed number of Global Mask Registers (GMR) 64 72-bit GMRs which can be combined to support larger database widths For the 144-bit database that would probably be used for an IPv4 GM Filter database, there would only be 32 GMRs. For example, in an IPv4 MR, these would be used for General Match filters that have masks for address fields, a wildcard for the protocol field and ranges for transport port fields. The issue is that to support a general range capability for transport port fields, we might consume a large number of GMRs for one GM Filter. Basically you have to define a series of Lookup Entries, each with its own GMR that covers the whole range of ports needed. I believe the worst case is to cover a 16-bit port range of 0x0001-0xFFFE we might need 30 entries with 14 GMRs. I’m still investigating.