Design of a Diversified Router: Project Assignments and Status Updates

1
Design of aDiversified Router Project
Assignmentsand Status Updates
John DeHartjdd_at_arl.wustl.edu http//www.arl.wust
l.edu/arl
2
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

3
Project Assignments

• 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

4
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?

5
4/25/06 Update

• QM/Scheduler Status
• Amy
• 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.

6
4/25/06 Update

• MR Parse and MR Hdr Format Status
• Implementing two MRs
• IPv4
• MPLS
• Well 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.
• IPv4 Hdr Format Block
• Jing understands what the Hdr Format Block needs
  to do and will be working on pseudo code for it.

7
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.

8
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
  interfaces 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.

9
4/25/06 Update

• LC Hdr Format Block Status
• No status update.

10
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.
• Im still investigating.