1. Design of a Diversified Router: TCAM Usage
John DeHart

2. TCAM Issues CAM Size: Segments: Data: 256K 72-bit entries
Organized into Segments.
Mask: 256K 72-bit entries
Segments:
Each Segment is 8k 72-bit entries
32 Segments
Minimum database size is therefore 8K 72-bit entries.
Segments are not shared between Databases.
Do databases wider than 72-bits use multiple parallel segments or do they use sequential entries in a segment to make up the long entries?
Sequential entries are used to comprise one longer entry.
36b DB has 16K entries per segment
72b DB has 8K entries per segment
144b DB has 4K entries per segment
288b DB has 2K entries per segment
576b DB has 1K entries per segment
Can a segment be dynamically added to a Database as it grows?
Yes, more on this feature in a future issue of the IDT User Manual…

3. TCAM Issues Number of Databases available: 16
Database Core Sizes: 36b, 72b, 144b, 288b, 576b
Key and Entry size
Can be different for each Database.
<= Database Core Size
Result Type
Absolute Index
Database Relative Index
Memory Pointer
TCAM Associated Data of width 32, 64 or 128 bits
Memory Constraints:
TCAM Associated Data
512K x 36 bit ZBT SRAM
Supports 128K 128-bit Results
If used for Rx and Tx then 64K in each direction
IXP QDR SRAM Channel
2 x 2Mx18 (effective 4M x 18b)
4 times as much as the TCAM ZBT SRAM.
Supports 512K 128-bit Results
If used for Rx and Tx then 256K in each direction

4. TCAM Issues Mask Registers When are these used?
I think we will need one of these for each database that is to be used in a Multi Database Lookup (MDL), where the database entries do not actually use all the bits in the corresponding core size.
For example: a 32-bit lookup would have a core size of 36 bits and so would need a GMR configured as 0xFFFFFFFF00 to mask off the low order 4 bits when it is used in a MDL where there are larger databases also being searched.
64 72-bit Global Mask Registers (GMR)
Can be combined for different database sizes
36-bit databases have 31 out of a total of 64 GMRs
A bit in the configuration for a database selects which half of the GMRs can be used
A field in each lookup command selects which specific GMR is to be used with the lookup key.
Value of 0x1F (31) is used in command to indicate no GMR is to be used. Hence, 36-bit lookups cannot use all 32 GMRs in its half.
72-bit databases have 31 out of a total of 64 GMRs
Value of 0x1F (31) is used in command to indicate no GMR is to be used. Hence, 72-bit lookups cannot use all 32 GMRs in its half.
144-bit lookups have 32 GMRs available to it.
288-bit lookups have 16 GMRs available to it.
576-bit lookups have 8 GMRs available to it.
Each lookup command can have one GMR associated with it.

5. TCAM Issues Types of Lookups supported: Types of Databases: LC: NP/MR:
Lookup (Direct)
Multi-Hit Lookup (Direct)
Simultaneous Multi-Database Lookup (Direct)
Multi-Database Lookup (Indirect)
Simultaneous Multi-Database Lookup (Indirect)
Re-Issue Multi-Database Lookup (Indirect)
Types of Databases:
Longest Prefix Match (LPM):
Uses Ternary capability of TCAM
Exact Match (EM)
Does not use Ternary capability of TCAM
Best/Range Match: What we typically call General Match.
LC:
All Databases for RX and TX will be Exact Match
NP/MR:
Probably will support up to 3 databases:
Route Lookup (LPM)
Exact Match
General Match (Best/Range Match)

6. TCAM Issues Performance Impacts IXP/TCAM Interface
16 bits wide
200 MHz QDR
Effective 32bits per clock tick
Example: 128b results from ZBT SRAM via TCAM: 4 ticks  max of 50M results/sec
Key Size (200MHz, 16 bit Interface for commands)
Rates are max PER LA-1 Interface, up to CAM Core max rate
32b (1W): 50M Lookups/sec (CAM Core constraint)
36b (2W): 50M Lookups/sec (CAM Core constraint)
64b (2W):100M Lookups/sec (Interface constraint)
72b (3W): 67M Lookups/sec (Interface constraint)
128b (4W): 50M Lookups/sec (Interface constraint)

7. TCAM Issues Performance Impacts (continued) Result Type
Index or Pointer Types:
Key Size: Max CAM Core lookup rate
36b: 50M/sec
72b: 100M/sec
144b: 100M/sec
288b: 50M/sec
576b: 25M/sec
Associated Data: CAM Core rates:
These rates are Total across both LA-1 Interfaces
Key Size: (32b Result Rate, 64b Result Rate, 128b Result Rate)
36b: , 50, 25
72b: 100, 50, 25
144b: 100, 50, 25

8. TCAM Performace Tables

9. TCAM Performace Graphs

10. TCAM Performace Graphs

11. LC: Notes on TCAM Lookups
The following slides show a way to use the TCAM for the lookups.
Slight adjustments might be desirable depending on:
Ease of doing operations on non-byte length bit fields
What we learn about methods for using the TCAM.
Field and Identifier sizes:
MN id: 32 bits
MI id: 16 bits (64K Meta Interfaces per Meta Router)
MLI: bits (64K Meta Links per Substrate Link)
Port: bits (256 Physical Interfaces per Line Card)
QID: bits (128K Queues per Queue Manager)
QM ID: 3 bits (8 Queue Managers per LC or PE.)
We probably can only support 4 QMs (2 bits)
(64 Q-Array Entries) / (16 CAM entries)  4 QMs per SRAM Controller.

12. LC: Notes on TCAM Lookups
Lookup Key size options:
32/36, 64/72, 128/144, 256/288, 512/576 (all in bits)
Lookup Result options:
Absolute Index: relative to beginning of TCAM array
Database Relative Index: relative to beginning of selected database
Memory Pointer Index: points to SRAM location of result data
Associated Data: 32, 64 or 128 bits of data associated with the lookup result.
Associated Data is stored in ZBT SRAM attached to TCAM.
TCAM Databases
How many to use?
1 for TX and 1 for RX?
1 for TX and 1 for each of the SL Types on Rx (5 types)?
Other…

13. LC: TCAM Lookup Keys on RX
Each SL Type will use a different Database on RX
Thus we do not need an SL Type field in the Key
SL Type ID will be used to identify which database to use
P2P-DC(24b):
SL Type ID: 0x0
Key Fields: Port(8)/MLI(16)
P2P-Tunnel(IPv4)(72b):
SL Type ID: 0x1
Key Fields: Port(8)/EtherType(16)/IPSrc(32)/MLI(16)
P2P-VLAN0(72b):
SL Type ID: 0x2
Key Fields: Port(8)/EthSAddr(48)/MLI(16)
MA(24b):
SL Type ID: 0x3
Legacy(24b):
SL Type ID: 0x4
Key Fields: Port(8)/EtherType(16)
Key Fields:
Port(8b): Physical Interface number
MLI(16b): Meta Link Identifier
Ethertype(16b): Ethernet Header Type field
IPSrc(32b): IP Source Address
EthSAddr(48b): Ethernet Header Source Address

14. LC: TCAM Lookup Keys on RX
P2P-DC
Port(8b)
MLI(16b)
24 bits
IPv4 Tunnel
Port (8b)
EtherType (16b)
0x0800
IP SAddr (32b)
MLI (16b)
72 bits MA
Port (8b)
Ethernet SAddr (48b)
MLI (16b)
72 bits
P2P-VLAN0
Port(8b)
MLI(16b)
24 bits
Legacy
Port (8b)
EtherType (16b)
0x0800
24 bits
DstAddr (6B)
Blue Shading: Determine SL Type
Black Outline: Key Fields from pkt
DstAddr (6B)
SrcAddr (6B)
SrcAddr (6B)
Type=802.1Q (2B)
Type=802.1Q (2B)
TCI ≠ VLAN0 (2B)
TCI ≠ VLAN0 (2B)
Type=802.1Q (2B)
MLI (2B)
LEN (2B)
Meta Frame
TCI (2B)
Type=Substrate (2B)
PAD (nB)
CRC (4B)
DstAddr (6B)
SrcAddr (6B)
Type=IP (2B)
Multi-Access
Type=802.1Q (2B)
MLI (2B)
LEN (2B)
Meta Frame
TCI≠VLAN0 (2B)
Type=Substrate (2B)
PAD (nB)
CRC (4B)
DstAddr (6B)
SrcAddr (6B)
Type=802.1Q (2B)
MLI (2B)
LEN (2B)
Meta Frame
TCI=VLAN0 (2B)
Type=Substrate (2B)
PAD (nB)
CRC (4B)
DstAddr (6B)
SrcAddr (6B)
P2P-VLAN0
Type=IP (2B)
Ver/HLen/Tos/Len (4B)
Ver/HLen/Tos/Len (4B)
ID/Flags/FragOff (4B)
ID/Flags/FragOff (4B)
TTL (1B)
TTL (1B)
Protocol=Substrate (1B)
Protocol (1B)
Hdr Cksum (2B)
Hdr Cksum (2B)
Src Addr (4B)
Src Addr (4B)
Dst Addr (4B)
Dst Addr (4B)
MLI (2B)
IP Payload
LEN (2B)
Meta Frame
PAD (nB)
PAD (nB)
CRC (4B)
CRC (4B)
P2P-DC
Configured
P2P-Tunnel
Legacy

15. LC Packet RX: All SL Types
Type=IP (2B)
MLI (2B)
LEN (2B)
PAD (nB)
CRC (4B)
Meta Frame
Dst Addr (4B)
Src Addr (4B)
Ver/HLen/Tos/Len (4B)
ID/Flags/FragOff (4B)
TTL (1B)
Protocol=Substrate (1B)
Hdr Cksum (2B)
Type=802.1Q (2B)
TCI ≠ VLAN0 (2B)
DstAddr (6B)
SrcAddr (6B)
Type=802.1Q (2B)
MLI (2B)
LEN (2B)
Meta Frame
TCI (2B)
Type=Substrate (2B)
PAD (nB)
CRC (4B)
DstAddr (6B)
SrcAddr (6B)
Type=802.1Q (2B)
MLI (2B)
LEN (2B)
Meta Frame
TCI=VLAN0 (2B)
Type=Substrate (2B)
PAD (nB)
CRC (4B)
DstAddr (6B)
SrcAddr (6B)
Type=802.1Q (2B)
MLI (2B)
LEN (2B)
Meta Frame
TCI≠VLAN0 (2B)
Type=Substrate (2B)
PAD (nB)
CRC (4B)
DstAddr (6B)
SrcAddr (6B)
P2P-DC
P2P-Tunnel
P2P-VLAN0
Multi-Access

16. LC: TCAM Lookup Results on RX
Fields (68b/128b):
It would be advantageous if this was 64 bits. The associated data SRAM with the NSE has widths of 32, 64 or 128 bits.
VLAN (16b)
We could probably drop this to 12b since our switch is supposed to only support 4K VLANs but we might want to leave this open to switches supporting larger numbers of VLANs.
MI (16b)
Blade Eth Hdr (8b)
Only needs to have the DAddr.
We can control the MAC Addresses of the Blades, so lets say that 40 of the 48 bits are fixed and 8 bits are assigned and stored in the Lookup Result. Even 8 bits is overkill but it leaves us some flexibility.
SAddr can be configured and constant per LC
First EtherType can be constant: 802.1Q
Second EtherType can be constant: Substrate
QID (20b)
MnFlags(8b):
NhAddr(60b): If needed

17. LC: TCAM Lookup Results on RX
Can we say there will be no Pass Through Meta Links where one side will be on a Multi Access and hence might need a NhAddr field?
If so then we can drop the MnFlags and NhAddr fields from result
Result size then becomes: 60b
Pass Through Meta Link Fields:
MnFlags(8b)
NhAddr(nB)
We have 60 bits left over that could be used for NhAddr
If we need more, options:
Do a second lookup with the following fields to retrieve the Next Hop bits from another Database for NH Bits?
Port (8b)
VLAN (16b)
MI (16b)
If the size indicated in the MnFlags is greater than 60 bits, use put an Memory Pointer in the bits after the MnFlags and lookup the NhAddr in memory.
We could even include 32 bits of the NhAddr in the original TCAM result and still have a memory pointer to get the rest. This might cut down on memory access time needed to retrieve the NhAddr.

18. Rx Handling NhAddr for Pass-Through MLs
For Tx to handle Multi-Access Substrate Links we need to provide an ARP capability on behalf of the MetaNets.
To do this we need the MRs to give the LCs a MN Next Hop Address that the LC-TX will do a lookup on to see if we have a MAC address for and if not, issue an ARP to request it.
But, the LC does not know how large the MN NhAddr might be.
Included in the MnFlags fields is the size so Tx can handle variable sizes.
But what is a good limit?
IPv4 is 32 bits
IPv6 is 128 bits
But IPv6 uses Neighbor Discovery to do what ARP does, and it does more.
The MnFlags field has a 6 bit length in bytes, so it can be up to 63 bytes
For Pass Through MetaLinks where one side is MA we need the LC-RX to have in its lookup result the Next Hop Address so the Tx can do the translation to MAC address in the same way.
Can we assume that this won’t happen?
Actually it is probably fairly likely to happen on access links. Perhaps the MetaNet does not have a MR located at the first Substrate Router but its access MetaLinks pass-through
If we find that we have to store the MnNhAddr in the Rx Result, I think we can make it variable sized by using Multi-Hit Lookups (MHL) and storing the same Key multiple times with different results for each one.
Each subsequent result would be the additional bits to concatenate on to the MnNhAddr.
In the Results Mailbox for a MHL, we can have at most
250 bits in bit AD Results or 244 bits in 4 64-bit AD Results or 232 bits in 8 32-bit AD Results
So, lets assume that in general we don’t need the NhAddr in the Rx entry. (next slide…)

19. Rx Handling NhAddr for Pass-Through MLs
Rx Result (61 bits)
VLAN (16b)
MI (16b)
Blade Eth Hdr (8b)
QID (20b)
Continuation bit (1b):
0: no need for MnFlags and NhAddr, MHL should report MHit of 0
1: MnFlags and NhAddr contained in subsequent results, MHL should report MHit of 0.
This then leaves us 3 more possible results to the MHL, giving us (3*61)-8 = 155 bits of Next Hop Address.
We have to be careful when writing the entries for Rx:
We write the main and subsequent entries in the right order.
I assume that the order of the results is based on the priority of the entries in the TCAM which is determined by order.
The continuation bit is set correctly.
Actually this is just a safety check. If we always do a MHL then the MH bit in the result should tell us if there are subsequent results.

20. LC: TCAM Lookups on TX Key: Result VLAN(16b) TxMI(16b)
The Lookup Result for TX will consist of several parts:
Lookup Result
Constant fields
Calculated fields
Fields that can be stored in Local Memory
Some of these are common across all SL Types
Other fields are specific to each SL Type
Common across all SL Types (96b):
From Result (48b)
SL Type(4b)
Port(8b)
MLI(16b)
QID (20b)
Local Memory (48b)
Eth Hdr SA (48b) : tied to Port
SL Type Specific Headers
P2P-DC Hdr:
P2P-MA Hdr:
P2P-VLAN0 Hdr
P2P-Tunnel Hdr for IPv4 Tunnel

21. LC: TCAM Lookups on TX Key: Result VLAN(16b) TxMI(16b)
Common across all SL Types (96b):
From Result (48b)
SL Type(4b)
Port(8b)
MLI(16b)
QID (20b)
Local Memory (48b)
Eth Hdr SA (48b) : tied to Port
SL Type Specific Headers
P2P-DC Hdr (64b)
Constant (16b)
EtherType (16b) = Substrate
Calculated (0b)
Eth DA (48b)
Lookup Result Total (Common From Result + Specific From Result): 96 bits
Total (Common + Specific) : 160 bits

22. LC: TCAM Lookups on TX Key: Result VLAN(16b) TxMI(16b)
Common across all SL Types (96b):
From Result (48b)
SL Type(4b)
Port(8b)
MLI(16b)
QID (20b)
Local Memory (48b)
Eth Hdr SA (48b) : tied to Port
SL Type Specific Headers
MA Hdr (64b) :
Constant (16b)
EtherType (16b) = Substrate
Calculated (0b)
ARP Lookup on NhAddr (Is ARP cache another database in TCAM?) (48b)
Eth DA (48b)
From Result (0b)
Lookup Result Total (Common From Result + Specific From Result): 48 bits
Total (Common + Specific) : 160 bits

23. LC: TCAM Lookups on TX Key: Result VLAN(16b) TxMI(16b)
Common across all SL Types (96b):
From Result (48b)
SL Type(4b)
Port(8b)
MLI(16b)
QID (20b)
Local Memory (48b)
Eth Hdr SA (48b) : tied to Port
SL Type Specific Headers
MA with VLAN Hdr (96b) :
Constant (32b)
EtherType1 (16b) = 802.1Q
EtherType2 (16b) = Substrate
Calculated (0b)
ARP Lookup on NhAddr (Is ARP cache another database in TCAM?) (48b)
Eth DA (48b)
From Result (16b)
TCI (16b)
Lookup Result Total (Common From Result + Specific From Result): 64 bits
Total (Common + Specific) : 192 bits

24. LC: TCAM Lookups on TX Key: Result VLAN(16b) TxMI(16b)
Common across all SL Types (96b):
From Result (48b)
SL Type(4b)
Port(8b)
MLI(16b)
QID (20b)
Local Memory (48b)
Eth Hdr SA (48b) : tied to Port
SL Type Specific Headers
P2P-VLAN0 Hdr (80b):
Constant (16b)
EtherType1 (16b) = 802.1Q
EtherType2 (16b) = Substrate
Calculated (0b)
From Result (64b)
Eth DA (48b)
TCI (16b)
Lookup Result Total (Common From Result + Specific From Result): 112 bits
Total (Common + Specific) : 176 bits

25. LC: TCAM Lookups on TX Result (continued)
Common across all SL Types (96b):
From Result (48b)
SL Type(4b)
Port(8b)
MLI(16b)
QID (20b)
Local Memory (48b)
Eth Hdr SA (48b) : tied to Port
SL Type Specific Headers
P2P-Tunnel Hdr for IPv4 Tunnel (224b):
Constant (64b)
Eth Hdr EtherType (16b) = 0x0800
IPHdr Version(4b)/HLen(4b)/Tos(8b) (16b): All can be constant?
IP Hdr Flags(3b)/FragOff(13b) (16b) : what is our stance on Fragments? If never used, these are constants, if it is possible we will have to use them, then this has to be calculated. Either way, shouldn’t be in Result
IP Hdr TTL (8b): ???
IP Hdr Proto (8b) = Substrate
Calculated (48b)
IP Hdr Len(16b) : needs to be calculated for each packet sent, so shouldn’t be in Result.
IP Hdr ID(16b): should be unique for each packet sent, so shouldn’t be in Result.
IP Hdr Checksum (16b): Needs to be calculated, so shouldn’t be in Result.
Local Memory (32b)
IP Hdr Src Addr (32b) : tied to physical interface (10 entry table)
From Result (80b)
Eth Hdr DA (48b)
IP Hdr Dst Addr (32b)
Lookup Result Total (Common From Result + Specific From Result): 128 bits
Total (Common + Specific) : 320 bits

26. LC: TCAM Lookups on TX Key: Result VLAN(16b) TxMI(16b)
Common across all SL Types (96b):
From Result (48b)
SL Type(4b)
Port(8b)
MLI(16b)
Ignored for Legacy Traffic
QID (20b)
Local Memory (48b)
Eth Hdr SA (48b) : tied to Port
SL Type Specific Headers
Legacy (IPv4) with VLAN Hdr (96b):
Constant (16b)
EtherType1 (16b) = 802.1Q
Calculated (0b)
ARP Lookup on NhAddr (Is ARP cache another database in TCAM?) (48b)
Eth DA (48b)
From Result (32b)
EtherType2 (16b) = IPv4
TCI (16b)
Lookup Result Total (Common From Result + Specific From Result): 80 bits
Total (Common + Specific) : 192 bits

27. LC: TCAM Lookups on TX Key: Result VLAN(16b) TxMI(16b)
Common across all SL Types (96b):
From Result (48b)
SL Type(4b)
Port(8b)
MLI(16b)
Ignored for Legacy Traffic
QID (20b)
Local Memory (48b)
Eth Hdr SA (48b) : tied to Port
SL Type Specific Headers
Legacy (IPv4) without VLAN Hdr (64b):
Constant (0b)
Calculated (0b)
ARP Lookup on NhAddr (Is ARP cache another database in TCAM?) (48b)
Eth DA (48b)
From Result (16b)
EtherType (16b) = IPv4
Lookup Result Total (Common From Result + Specific From Result): 64 bits
Total (Common + Specific) : 160 bits

28. SUMMARY: LC: TCAM LookupsDC
Tunnel
VLAN0 MA w/
vlan
w/o
Legacy w/ vlan
Legacy w/o vlan RX
Key 24 72
Result
61* TX 32 96
128
112 64 48 80
Rx Key: 72 bits
Rx Result Size: 61* bits
61 bits if there is no need for NhAddr
Multiple results if there is a need for NhAddr, see earlier discussion.
Tx Key Size: 32 bits
Tx Result Size: 128 bits
We need to watch out for the Tx Result for Tunnels. If we introduce anything else we want in there then we go beyond the 128 bits supportable through the TCAM’s Associated memory.

29. Databases on LC Rx: TX: 0000: DC 0001: IPv4 Tunnel 0010: VLAN0
0011: MA (with or without VLAN)
0100: Legacy (non-substrate) with or without VLAN
TX:
1000: all TX lookups use one database

30. Extra
The next set of slides are for templates or extra information if needed

31. Text Slide Template

32. Image Slide Template

33. OLD
The rest of these are old slides that should be deleted at some point.

34. LC: TCAM Lookup Keys on RX
P2P-DC(28b): SL_Type(4)/Port(8)/MLI(16)
P2P-Tunnel(IPv4)(76b): SL_Type(4)/Port(8)/EtherType(16)/IPSrc(32)/MLI(16)
P2P-VLAN0(76b): SL_Type(4)/Port(8)/EthSAddr(48)/MLI(16)
MA(28b): SL_Type(4)/Port(8)/MLI(16)
Legacy(28b): SL_Type(4)/Port(8)/EType(16)
Fields:
SL_Type (4b): Substrate Link Type
0000: DC
0001: IPv4 Tunnel
0010: VLAN0
0011: MA
0100: Legacy (non-substrate) without VLAN
0101: Legacy (non-substrate) with VLAN
Port(8b): Physical Interface number
MLI(16b): Meta Link Identifier
Ethertype(16b): Ethernet Header Type field
IPSrc(32b): IP Source Address
EthSAddr(48b): Ethernet Header Source Address

35. Databases on LC
Rx:
0000: DC
0001: IPv4 Tunnel
0010: VLAN0
0011: MA
0100: Legacy (non-substrate) without VLAN
0101: Legacy (non-substrate) with VLAN
TX:
1000: all TX lookups use one database
Do we really need to use the TCAM for TX Lookups?
VLAN(16b)/TxMI(16b) is the lookup key.
Really only 4K VLANs support: 12 bits
How many VLANs (i.e. MRs) should be supported per LC?
How many MIs should be supported per MR?
8MB per SRAM/(16B per Lookup)  512K Entries

36. LC: TCAM Lookup Results on RX
Standard Fields (64b/128b):
Type (4b): Probably don’t need this since there is a size in MnFlags.
0000: Default, not Pass Through, ignore MnFlags
1000: Pass Through with no extra lookup needed for NhAddr(nB), MnFlags(8b) should be 0x00
1001: Pass Through with extra lookup needed for NhAddr(nB)
VLAN (16b)
MI (16b)
Blade Eth Hdr (8b)
Only needs to have the DAddr.
We can control the MAC Addresses of the Blades, so lets say that 40 of the 48 bits are fixed and 8 bits are assigned and stored in the Lookup Result. Even 8 bits is overkill but it leaves us some flexibility.
SAddr can be configured and constant per LC
First EtherType can be constant: 802.1Q
Second EtherType can be constant: Substrate
QID (20b)
MnFlags(8b): If needed
NhAddr(56b): If needed

37. SUMMARY: LC: TCAM LookupsDC
Tunnel
VLAN0 MA
Legacy w/ vlan
Legacy w/o vlan RX
Key 28 76
Result
64/128 TX 32 96
128
112 80 64
Result in Loc. Mem 48
Combined
148
212
164
132
116
Rx Key Size: 128 bits
If We dropped the SL Type field and just made each SL Type a separate Database then we could get the RX Key down to 72 bits
Rx Result Size: 64/128 bits
Depends on whether we need to support MA on other end of pass through MetaLink and on what size the NhAddr needs to be.
Tx Key Size: 32 bits
Tx Result Size: 128 bits
We need to watch out for the Tx Result for Tunnels. If we introduce anything else we want in there then we go beyond the 128 bits supportable through the TCAM’s Associated memory.
If we find we can’t use the 128 bit Result size for Tx, we might as well include the Local Memory result in the TCAM lookup.
The Local Memory result was going to be the data that was only dependent on the Physical Interface id and was going to go into Local memory to try to keep the TCAM result below 128 bits.

38. LC: TCAM Lookup Keys on RX
SL(4b)
0000
Port(8b)
MLI(16b)
PAD(100b)
SL (4b)
0001
Port (8b)
EtherType (16b)
0x0800
IP SAddr (32b)
MLI (16b)
PAD (52b)
SL (4b)
0010
Port (8b)
Ethernet SAddr (48b)
MLI (16b)
PAD (52b)
SL(4b)
0011
Port(8b)
MLI(16b)
PAD(100b)
SL (4b)
0100
Port (8b)
EtherType (16b)
0x0800
PAD (100b)
DstAddr (6B)
Blue Shading: Determine SL Type
Black Outline: Key Fields from pkt
DstAddr (6B)
SrcAddr (6B)
SrcAddr (6B)
Type=802.1Q (2B)
Type=802.1Q (2B)
TCI ≠ VLAN0 (2B)
TCI ≠ VLAN0 (2B)
Type=802.1Q (2B)
MLI (2B)
LEN (2B)
Meta Frame
TCI (2B)
Type=Substrate (2B)
PAD (nB)
CRC (4B)
DstAddr (6B)
SrcAddr (6B)
DstAddr (6B)
DstAddr (6B)
Type=IP (2B)
Type=IP (2B)
Ver/HLen/Tos/Len (4B)
ID/Flags/FragOff (4B)
SrcAddr (6B)
SrcAddr (6B)
Ver/HLen/Tos/Len (4B)
ID/Flags/FragOff (4B)
TTL (1B)
Type=802.1Q (2B)
Type=802.1Q (2B)
TTL (1B)
Protocol=Substrate (1B)
Hdr Cksum (2B)
TCI=VLAN0 (2B)
TCI≠VLAN0 (2B)
Protocol (1B)
Src Addr (4B)
Type=Substrate (2B)
Type=Substrate (2B)
Hdr Cksum (2B)
MLI (2B)
MLI (2B)
Src Addr (4B)
Dst Addr (4B)
LEN (2B)
LEN (2B)
Dst Addr (4B)
MLI (2B)
Meta Frame
Meta Frame
IP Payload
LEN (2B)
Meta Frame
PAD (nB)
PAD (nB)
PAD (nB)
PAD (nB)
CRC (4B)
CRC (4B)
CRC (4B)
CRC (4B)
P2P-DC
Configured
P2P-Tunnel
P2P-VLAN0
Multi-Access
Legacy

39. TCAM Issues Global Mask Register Usage Examples
IPv4 Route Lookup Database (Longest Prefix Match)
32-bit Entries and Keys
Uses a core database size of 36 bits
31 available GMRs
Entries of the form:
Prefix/prefix length
Each Entry would use a GMR corresponding to the prefix length
Prefix length=24  GMR with a value of 0xFFFFFF00
The number of different values of prefix length used in the database defines the number of used GMRs.
A Mae West database that we once used in our PI Mtg Demo had 24 different prefix lengths (8-30, 32)
Using this database would only leave 7 GMRs in its half of the GMR space.
So, we basically have to set aside half of the GMRs for Route Lookup.

40. TCAM Issues Global Mask Register Usage Examples
IPv4 General Match Filter Database (Best/Range Match)
116-bit Entries and Keys
Uses a core database size of 144 bits
32 available GMRs
Entries of the form:
DAddr/prefix_length
SAddr/prefix_length
DPort Range(min, max)
Sport Range(min, max)
Protocol
Protocol Wildcard
TCP Flags/Mask
Example:
Entry for catching all X-windows packets FROM a 24-bit subnet
DAddr: /0 (don’t care)
SAddr: /24
DPort: (X-Windows TCP and UDP Port Numbers)
Sport: *, (don’t care, lets assume it is just the Destination Port that matters)
Protocol: 6 or 17 (TCP or UDP)
TCP_Flags: * (don’t care)
Port Range: AF
Ternary values for Port range of
**** (0x1770 – 0x177F)
* **** (0x1780 – 0x179F)
**** (0x17A0 – 0x17AF)

41. TCAM Issues Global Mask Register Usage Examples
IPv4 General Match Filter Database (Best/Range Match)
GMR bits for SAddr ( /24. 0xC0A82800/24)
(SAddrMask)
GMR bits for DAddr(*)
(DAddrMask)
GMR bits for Port range of
**** : with a value of 0x1770 (DPortMask-1)
* **** : with a value of 0x1780 (DPortMask-2)
**** : with a value of 0x17A0 (DPortMask-1)
GMR bits for SPort(*)
(SPortMask)
GMR bits for Protocol (6 or 17)
(ProtocolMask)
With an entry each for 6 and 17
GMR bits for TCP Flags
(TCP_Mask)
Masks: we have two Masks:
Mask-1: with SAddrMask, DAddrMask, DPortMask-1, SPortMask, ProtocolMask, TCP_Mask)
Mask-2: with SAddrMask, DAddrMask, DPortMask-2, SPortMask, ProtocolMask, TCP_Mask)
Entries: we have 6 Entries
Entry-1: Mask-1 with DPort=0x1770 and Protocol=6
Entry-2: Mask-1 with DPort=0x1770 and Protocol=17
Entry-3: Mask-1 with DPort=0x17A0 and Protocol=6
Entry-4: Mask-1 with DPort=0x17A0 and Protocol=17
Entry-5: Mask-2 with DPort=0x1780 and Protocol=6
Entry-6: Mask-2 with DPort=0x1780 and Protocol=17