|
ࡱ > R K bjbj B ! ! . . . . . 4 / / / h o/ 0 / h 72 7 p 7 7 7 F }L !N X 6 . O F F O O . . 7 7 DX DX DX O @ . 7 . 7 DX O DX DX f V 7 jۙd / S ݈ D 0 ! 0 U N 0 " 0 . N " O DX /O CO N N N >W N N N O O O O 0 N N N N N N N N N ! - :
Embedded Protocol Analyzing Classifier Design Document
Version 1.0.8
April 25, 2007
Technica Corporation
45245 Business Court, Suite 300
Dulles, VA 20166
703.662.2000 phone
703.662.2001 fax
www.technicacorp.com
Table of Contents
TOC \o "1-3" \h \z \t "Heading 4,4,Heading 5,5,Heading 6,6,Heading 7,7,Heading 8,8,Heading 9,9" HYPERLINK \l "_Toc165286295" 1 Introduction PAGEREF _Toc165286295 \h 1
HYPERLINK \l "_Toc165286297" 2 Design Objectives PAGEREF _Toc165286297 \h 2
HYPERLINK \l "_Toc165286298" 3 Functional Description PAGEREF _Toc165286298 \h 3
HYPERLINK \l "_Toc165286299" 3.1 Protocol Memory PAGEREF _Toc165286299 \h 4
HYPERLINK \l "_Toc165286300" 3.2 Assembler PAGEREF _Toc165286300 \h 4
HYPERLINK \l "_Toc165286302" 3.3 Length Saver PAGEREF _Toc165286302 \h 5
HYPERLINK \l "_Toc165286303" 3.3.1 Calculating Length PAGEREF _Toc165286303 \h 6
HYPERLINK \l "_Toc165286304" 3.4 Protocol Saver PAGEREF _Toc165286304 \h 6
HYPERLINK \l "_Toc165286305" 3.4.1 Jump Block PAGEREF _Toc165286305 \h 6
HYPERLINK \l "_Toc165286306" 3.5 Port Block PAGEREF _Toc165286306 \h 7
HYPERLINK \l "_Toc165286308" 3.5.1 Loading New Port Values PAGEREF _Toc165286308 \h 9
HYPERLINK \l "_Toc165286309" 4 Summary PAGEREF _Toc165286309 \h 9
HYPERLINK \l "_Toc165286310" Acronym List PAGEREF _Toc165286310 \h 10
List of Figures
TOC \h \z \c "Figure" HYPERLINK \l "_Toc165281170" Figure 1. EmPAC Top Level Design PAGEREF _Toc165281170 \h 2
HYPERLINK \l "_Toc165281171" Figure 2. Internal Architecture of EmPAC PAGEREF _Toc165281171 \h 3
HYPERLINK \l "_Toc165281172" Figure 3. Phy_data Registers PAGEREF _Toc165281172 \h 5
HYPERLINK \l "_Toc165281173" Figure 4. Port Block Functional Description PAGEREF _Toc165281173 \h 8
List of Tables
TOC \h \z \c "Table" HYPERLINK \l "_Toc165281175" Table 1. Protocol Memory Signal Description PAGEREF _Toc165281175 \h 4
HYPERLINK \l "_Toc165281176" Table 2. Assembler Signal Description PAGEREF _Toc165281176 \h 5
HYPERLINK \l "_Toc165281177" Table 3. Length Saver Signal Description PAGEREF _Toc165281177 \h 5
HYPERLINK \l "_Toc165281178" Table 4. Length Saver Field Type Requirement PAGEREF _Toc165281178 \h 6
HYPERLINK \l "_Toc165281179" Table 5. Protocol Saver Signal Description PAGEREF _Toc165281179 \h 6
HYPERLINK \l "_Toc165281180" Table 6. Protocol Types and Values PAGEREF _Toc165281180 \h 7
HYPERLINK \l "_Toc165281181" Table 7. Jump Block Signal Description PAGEREF _Toc165281181 \h 7
HYPERLINK \l "_Toc165281182" Table 8. Port Block Signal Description PAGEREF _Toc165281182 \h 8
Introduction
The Embedded Protocol Analyzing Classifier (EmPAC) is designed to perform the task of packet classification through protocol analysis. Its goal is to take an unclassified byte stream coming from the Ethernet Physical Layer Interface (PHY) and partition and classify the data blocks into corresponding protocol fields. These include header information such as source and destination address, header and payload sizes, and protocol flags, as well as the payload fields themselves.
The partitioned data fields are output on a 32-bit bus, accompanied simultaneously by a unique 16-bit field type to identify not only the fields context (its associated protocol), but also its particular relevance (e.g., source address, payload size, and header checksum). EmPAC will support an interface to modules capable of analyzing certain Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) application layer protocols. Therefore, EmPAC must verify if the incoming application layer protocol is supported in the design. When supported, this verification must also be accompanied by the port value of the supported protocol. These port values are read from the PHY when the TCP or UDP source or destination port value arrives. Figure 1 depicts the top-level design of EmPAC. The associated signals are defined as follows:
Field_data contains the 32-bit partitioned data field.
Field_type contains the 16-bit field data identifier.
Data_ready, when asserted, validates the data located on field_type and field_data once the 32-bit partitioned data field is available.
Port_found, when asserted, the application layer protocol is supported in the design.
Port_value contains the value of the application layer protocol port number.
Load, when asserted, indicates that a new application layer protocol is available to be loaded into the design.
Load_data contains the 16-bit application layer protocol value.
EMBED Visio.Drawing.11
Figure SEQ Figure \* ARABIC 1. EmPAC Top Level Design
EmPAC supports the following internet protocols:
Physical Layer
Ethernet
Data Link Layer
Address Resolution Protocol (ARP)
Network Layer
Internet Protocol Version 4 (IPv4)
Internet Protocol Version 6 (IPv6)
Transport Layer
TCP
UDP
Thousands of application layer protocols appear after the transport layer. Therefore, EmPAC is designed with re-configurability, allowing the user to update the design with new application layer protocols.
Design Objectives
Figure 2 illustrates the internal design of the EmPAC first design option.
EMBED Visio.Drawing.11
Figure SEQ Figure \* ARABIC 2. Internal Architecture of EmPAC
Functional Description
EmPAC is capable of taking an incoming Ethernet frame stream and classifying each protocol field into its field type and placing the corresponding data onto the field_data signal. The field_type and field_data signals are validated by asserting the data_ready signal. This assures that the field_type and field_data have been completely assembled into a 32-bit vector. The load and load_data signals are used for reconfiguration when loading new application layer protocols. When the incoming application layer protocol is found, the port_found signal is asserted, and the corresponding application layer protocol value is placed on the port_value signal. The following sections explain the functionality of each module in detail.
Protocol Memory
This module contains the protocol information of all supported protocols listed below.
Ethernet
ARP
IP
IPv4
IPv6
TCP
UDP
The information contained in this memory is used to determine which field types are expected on the incoming data stream from the PHY. It will be embedded in the design using case statements to generate the signals listed in Table 1.
Table SEQ Table \* ARABIC 1. Protocol Memory Signal Description
Signal NameDirectionBit WidthDescriptionField_widthOUT2Contains the width in bytes of each protocol fieldBranch_indicatorOUT1Indicates when a branch to a different protocol within the protocol memory is requiredProtocol_indicatorOUT1Indicates that a protocol type is available on the incoming packetLength_indicatorOUT1Indicates that length information is available on the incoming packetVariable_length_fieldOUT1Indicates that the incoming field has a variable lengthPort_indicatorOUT1Indicates that the incoming field contains port informationField_typeOUT16Equivalent to the protocol memory address. It is also used as the protocol field classification valuesJump_addressIN8Address of protocol to jump to when the branch indicator is assertedEmbedding the data is possible because the protocol information stored will not require any alterations. This will present a faster frequency than the alternative solution of using a Read Only Memory (ROM) or a Random Access Memory (RAM). These memories tend to have maximum frequencies associated with them, which may limit the overall frequency of the design.
Assembler
This component is responsible for assembling the 8-bit data stream from the PHY into a 32-bit data stream. Bits 0 through 1 of length are used to determine how many bits should be zero padded when the length is less than 4 bytes. In the event that the length of the current field is greater than 4 bytes, the assembler will then assemble the entire 8-bit data stream into 32 bits without zero pads. If the length of variable length field is not a multiple of four, the remaining bits required to complete the 32-bit vector will be padded with zeros. Table 2 describes the ports and their functions.
Table SEQ Table \* ARABIC 2. Assembler Signal Description
Signal NameDirectionBit WidthDescriptionLengthIN16Contains the remaining length in bytes of the incoming protocol fieldPhy_dataIN8Contains the incoming packet to be classifiedField_dataOUT1Contains the data corresponding to each protocol field. When the protocol field is less than 32 bits, the remaining bits will be zero paddedData_readyOUT8Asserted when the 32-bit field data is completeTo avoid any possible delays, the incoming data stream is stored in registers. The assembler uses the concatenation of Q4, Q3, Q2, and Q1, respectively, as the 32 bits to be assembled as illustrated in Figure 3. The concatenation of D4, D3, D2, and D1 is available to all the other components in the design one cycle prior to assembling so that the necessary branching and length calculations may be determined.
EMBED Visio.Drawing.11
Figure SEQ Figure \* ARABIC 3. Phy_data Registers
Length Saver
The Length Saver is responsible for storing the length of the upcoming variable length field. Once activated, incoming field_data is stored temporarily. When the length of the current field type is unknown, the length stored by the Length Saver is used as the length of the current field type in place of the field width. The input and output signals of this module are listed in Table 3.
Table SEQ Table \* ARABIC 3. Length Saver Signal Description
Signal NameDirectionBit WidthDescriptionLength_indicatorIN1When asserted, the value located on field_data will be storedField_dataIN32Contains the assembled packet to be classifiedField_typeIN8Equivalent to the protocol memory address. It is also used as the protocol field classification valueLengthOUT16Contains the length of the upcoming variable length fieldThe field_type is used to determine which protocol field is currently available. This is necessary in order to determine which protocol the length came from so that the proper calculations may be made to generate the correct length of the upcoming variable length field.
Calculating Length
To calculate the length of the upcoming variable length field, the Length Block uses the following formulas:
In the case where the network layer header length is greater than 14 bytes
Length = total packet length network layer header length
Otherwise
Length = total packet length transport layer header length
The total packet length and the transport layer length are received from the field_data signal based on the value contained on field_type once the length_indicator signal is asserted. Table 4 illustrates the associated field_type value required to retrieve the data properly.
Table SEQ Table \* ARABIC 4. Length Saver Field Type Requirement
Data TypeField_type Value (in hexadecimal) Ipv4 Header Length18Total Packet Length1ATCP Header Length27UDP Header Length2FIpv6 Header Length35Protocol Saver
The Protocol Saver has the responsibility of saving all protocol information on the incoming packet. This value is used to determine the location in memory in which the Protocol Memory should branch. Once activated, this component will begin storing the protocol value located on the incoming data stream. This protocol value is then delivered to the Jump Block for further processing detailed in the next section. Table 5 contains the signals to and from the Protocol Saver with the associated descriptions.
Table SEQ Table \* ARABIC 5. Protocol Saver Signal Description
Signal NameDirectionBit WidthDescriptionProtocol_indicatorIN1When asserted, the value located on field_data will be storedField_dataIN32Contains the assembled packet to be classifiedProtocol_typeOUT16Contains the value of the next protocol type to be expected on the incoming packetJump Block
Similar to the Protocol Memory, all jump addresses are also embedded into the system via case statements. When a particular protocol is delivered to this component, it will return the address location of this protocol in the protocol memory. Table 6 illustrates the supported protocol types and values with their corresponding address location in the protocol memory. Table 7 represents the signals to and from the Jump Block with the corresponding signal descriptions.
Table SEQ Table \* ARABIC 6. Protocol Types and Values
Protocol TypeProtocol ValueProtocol Memory AddressEhternet000000ARP080607Ipv4080018Ipv686DD32TCP000623UDP00112D
Table SEQ Table \* ARABIC 7. Jump Block Signal Description
Signal NameDirectionBit WidthDescriptionProtocol_typeIN16Contains the width in bytes of each protocol fieldBranch_indicatorIN1Indicates when a branch to a different protocol within the protocol memory is requiredJump_addressOUT8Address of protocol to jump to when the branch indicator is assertedPort Block
Because there are thousands of port values available, it would be infeasible to embed all port values into the design. Therefore, the Port Block contains dynamically reconfigurable port registers. These registers contain the values of all supported application layer protocols. The Port Block will contain 69 preloaded port values, with the possibility of holding up to 128 different port values total. When the Port_indicator is asserted, this component will store the port value located on the incoming packet. Port_found will then be asserted only if the port_value has been located within the port registers. This is accomplished by loading the values of each register into one comparator, as shown in Figure 4. The comparator will simultaneously compare the value of each register with the value located on the field_data signal.
EMBED Visio.Drawing.11
Figure SEQ Figure \* ARABIC 4. Port Block Functional Description
To load new ports into the design, a load signal must be asserted, and the port_value must be placed simultaneously onto the load_data signal. The new ports will then be loaded sequentially, beginning with the first available address. If no new addresses are available (i.e., all 128 locations are occupied), new ports will be loaded, beginning with the first address. Table 8 descibes the functionality of each signal to and from the Port Block.
Table SEQ Table \* ARABIC 8. Port Block Signal Description
Signal NameDirectionBit WidthDescriptionLoadIN4When asserted, new port values may be loadedLoad_dataIN1Contains the port values to be loaded once load signal is assertedPort_indicatorIN1Indicates that a port value is available on the incoming packetPort_foundOUT1Indicates that current application layer protocol is supportedPort_valueOUT16Contains the value of the supported application layer protocolField_dataIN32Contains the assembled packet to be classifiedLoading New Port Values
The load_data value is available to all registers; however, the load signal is connected to each register via the load bus (illustrated in Figure 4). Because all new port values are loaded into the port registers sequentially, a 7-bit counter is used to select the proper register to be loaded. For example, when the load signal is asserted, if the value contained in the counter is 1010010 (decimal value 82), only the load signal of the 82nd register will be asserted, allowing this register to take the new port value located on load_data. Once all port registers have been filled, the counter will reset to zero to overwrite the port values that have been supported the longest.
Summary
EmPAC is capable of taking an unclassified byte stream coming from the PHY and partition and classify the data blocks into corresponding protocol fields. It supports the following protocols:
Physical Layer
Ethernet
Data Link Layer
Address Resolution Protocol (ARP)
Network Layer
Internet Protocol Version 4 (IPv4)
Internet Protocol Version 6 (IPv6)
Transport Layer
TCP
UDP
EmPAC also supports all application layer protocols appearing after the supported transport layer protocols. Its reconfiguration ability allows new application layer protocols to also be loaded during runtime.
Acronym List
AcronymDefinitionARPAddress Resolution ProtocolEmPACEmbedded Protocol Analyzing ClassifierIPInternet ProtocolIPv4Internet Protocol version 4IPv6Internet Protocol version 6PHYPhysical Layer InterfaceTCPTransmission Control ProtocolUDPUser Datagram Protocol
PAGE 144
Copyright 2009 Technica Corporation. All rights reserved. PAGE i
STYLEREF "Document Name" \* MERGEFORMAT Embedded Protocol Analyzing Classifier Design Document
STYLEREF "Document Name" \* MERGEFORMAT Embedded Protocol Analyzing Classifier Design Document
Copyright 2009 Technica Corporation. All rights reserved. PAGE 1
Copyright 2009 Technica Corporation. All rights reserved. PAGE 10
8 9 : ; C E F H I W X \ b c w εnnnnnYnU hVS2 )h#K h B* CJ aJ mH nH ph sH#h B* CJ aJ mH nH ph sH)h| h B* CJ aJ mH nH ph sHh| h B* CJ aJ ph h| h 5B* CJ aJ ph h 5B* CJ aJ ph h3{ hF h3{ h h
|