MT92220 Zarlink Semiconductor, MT92220 Datasheet - Page 52

• Manufacturer Part Number: MT92220
• Description: 1023 Channel Voice Over IP/AAL2 Processor
• Manufacturer: Zarlink Semiconductor

52
header can also be used to make decisions regarding the packet. With this ability, the MT92220 can ensure that
any packet containing a certain header will be deleted or always sent to the CPU buffer, for example.
The information indicating how to treat the various “next header” values is contained in the Next Header memory.
The information indicating how to treat the various “options” is contained in the Profile Memory, which will be shown
later in Figure 28. The format of the Next Header memory is the following:
6.3
Once the type of the packet has been found, it must be searched for in the look-up system. The packet will initially
be routed to a default node (i.e. the Initial Search Structure), depending on its packet type (see Table 13 for the
exhaustive list). The default node is the first step in deciding what to do with the packet: it may indicate that the
packet must be discarded, routed to the CPU packet buffer or routed back onto the network on ports A or B. It may
also indicate that a more detailed search must be performed on the packet: in this case, the packet will be
looked-up in a binary tree. Usually, the default node will only indicate a destination for broad classes of packets that
the chip cannot process itself: for example, IPvX packets, or non-IP packets. In the case of IP/UDP packets, the
binary tree search should always be performed. If a tree search is to be performed, the default node will indicate
which profile to use.
The MT92220 uses a binary tree approach to uniquely identify packets: each packet is given a 60-bit identification
key generated by performing a 56-bit CRC on the various protocol headers that it contains and completed by
adding the 4-bit profile number to the key. The headers used to generate the source key depend on the nature of
the packet: while non-IP packets cannot even be passed through the binary tree, for lack of recognizable headers,
null-encapsulated packets can only use the Flow Table Pointer associated to the packet and the RTP
synchronization source to form the identification key (if RTP is not present, the Flow Table Pointer alone will be
used). Non-UDP and fragmented packets will have a identification key based only on their source and destination
IP addresses. Finally, the identification key for IP/UDP packets will include the source and destination IP addresses,
source and destination UDP ports, and potentially the RTP synchronization source. The packet type determines
which of the three identification key formats be selected.
NH
Field
Look-up
Next header. Indicates what to do when the hardware encounters this “next header” value.
“00” = delete;
“01” = route as non-UDP / fragmented UDP (to software);
“10” = process next header in IPv6 only;
“11” = process next header in IPv4 and IPv6.
3Eh
0h
b 15
NH=248
NH=0
b14
b13
NH=249
NH=1
Table 14 - Fields and Description
b12
Figure 26 - Next Header Memory
b11
NH=250
NH=2
Zarlink Semiconductor Inc.
b10
NH=251
b9
NH=3
b8
NH=252
Description
b7
NH=4
b6
NH=253
b5
NH=5
b4
NH=254
b3
NH=6
b2
NH=255
b1
NH=7
b0