ATM OC-3/12/Ethernet IP Router Example Design
Application Note - Rev 1.0, 3/20/2002
Order Number: 278393-001
Information in this document is provided in connection with Intel® products. No license, express or implied, by estoppel or otherwise, to any intellectual
property rights is granted by this document. Except as provided in Intel’s Terms and Conditions of Sale for such products, Intel assumes no liability
whatsoever, and Intel disclaims any express or implied warranty, relating to sale and/or use of Intel products including liability or warranties relating to
fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. Intel products are not
intended for use in medical, life saving, or life sustaining applications.
Intel may make changes to specifications and product descriptions at any time, without notice.
Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for
future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.
The IXP1200 Network Processor may contain design defects or errors known as errata which may cause the product to deviate from published
specifications. Current characterized errata are available on request.
MPEG is an international standard for video compression/decompression promoted by ISO. Implementations of MPEG CODECs, or MPEG enabled
platforms may require licenses from various entities, including Int el Corporation.
This ATM OC-3 / Ethernet IP Router Example Design Application Note as well as the software described in it is furnished under license and may only
be used or copied in accordance with the terms of the license. The information in this manual is furnished for informational use only, is subject to
change without notice, and should not be construed as a commitment by Intel Corporation. Intel Corporation assumes no responsibility or liability for
any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document. Except as
permitted by such license, no part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means
without the express written consent of Intel Corporation.
Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.
Copies of documents which have an ordering number and are referenced in this document, or other Intel literature may be obtained by calling 1-800-
548-4725 or by visiting Intel’s website at http://www.intel.com.
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
1.0Introduction
Intel develops example software to demonstrate the capabilities of the IXP1200 Network Processor
Family. This document describes the implementation of example software demonstrating the
IXP1200, IXP1240, and IXP1250 in an ATM environment. In particular, this example design uses
the IXP12xx to route IP packets between ATM and Ethernet networks.
From the point of view of this example software, the IXP1240 and IXP1250 are synonymous - the
project utilizes their common hardware CRC feature; but is not aware of the IXP1250’s additional
ECC capability. The IXP1200, on the other hand, does not have hardware CRC support, and thus
supports only a software-CRC configuration.
This document serves as a companion to the comments in the source code, and is intended to
clarify the structure and general workings of th e design. The fo llowing material is covered: purp ose
and scope of the design; software partitioning and data flow, StrongARM
initialization; microengine functional block description; sub sy stem s and data structures; interthread signaling; project configuration; testing environments; simulation support; limitations, and
example design extension. The end of this document contains lists of document conventions,
acronyms and definitions, and related documents.
1.1Purpose of ATM Example Design
®
Core and microengine
This example design demonstrates just one software architectu re in which the IXP12x x can be used
in ATM-related designs. It is not intended to be ’production ready’. Rather , it is intended to serve as
a starting point for customers designing similar applications. It is also intended for customers to
understand the IXP12xx Network Processor’s capabilities and expected performance.
Users may modify the code, adding additional modules that are proprietary or more specific to their
needs, and estimate performance, although performance numbers gained from this design are
applicable only to the example as presented. Customer changes to the design can result in either
increases or decreases in performance.
1.2Scope of Example Design
This document describes the implementation in sufficient detail that a programmer should b e able
to successfully modify the source code. The README.txt file that accompanies the software
should be consulted for instructions on running the project, building the code, and the actual layout
of the source files.
Application Note7
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
1.2.1Supported / Not Implemented Functions
The following identifies the ATM, Ethernet, and StrongARM supported functions, as well as those
functions that are not su pported.
ATM SupportEthernet Support
1xOC-12 port or up to
4xOC-3 ports (full-duplex).
Segmentation and Reassembly (SAR).
ATM Adaptation Layer 5
(AAL5 with CRC-32).
IP over ATM LLC/SNAP
Encapsulation.
Routing from ATM to
Ethernet ports based on IP.
Unspecified Bit Rate
(UBR).
Full ATM VC name space.
16K Virtual Circuits (VC)
simultaneously in use.
Up to 8 100Mbps
Ethernet ports (full
duplex).
Routing from
Ethernet to ATM
ports based on IP.
StrongARM Core
Processing Hooks
RFC1812 compliance.
AAL5 Protocol data units
(PDUs) for signaling,
(ILMI, LECS, PNNI, CIP)
forwarded to the
StrongARM core.
NOT Implemented
Control Plane processing.
ATM Traffic shaping.
ATM ARP support.
The majori ty of RFC1812 router validations are performe d i n the layer 3 forwardin g code running
on the microengines, while rare case exception packets are sent to the StrongARM core control
plane for validation and processing. No processing code on the StrongARM core is currently
implemented. Refer to the document "IXP1200 Network Processor RFC 1812 Compliant Layer 3
Forwarding Example Design Implementation Details" for further information.
This example design can be configured to run in three different hardware/software configurations
(see the README.TXT file for further information):
ConfigurationDescription
One ATM OC-12 port and eight
100Mbps Ethernet ports
Four ATM OC-3 ports and eight
100Mbps Ethernet ports
Two ATM OC-3 ports and four
100Mbps Ethernet ports
For use with the IXP1240/1250, which uses hardware CRC capability.
Similar to the above configuration (requires the IXP1240/50), except that
it uses four OC-3 ports.
For use with the IXP1200 (which does not have hardware CRC
capability). Instead, CRC computation is performed by two microengines
(thus the reduced data rates).
1.3Background
1.3.1Ethernet, IP and AAL5 Protocol Processing
Figure 1 identifies how this design processes Ethernet, IP , an d AAL5 protocols., Reading from top
to bottom, Ethernet packets go through the LLC/SNAP Encapsulation, followed by segmentation
into ATM AAL5 cells. Reading from bottom to top, it also shows the reverse process, in which
AAL5 cells are reassembled into Ethernet packets.
8Application Note
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
Figure 1. IP over ATM Encapsulation Format
Ethernet
to ATM
Ethernet
Data
Enet HeaderIP Packet
IP
Data
(LLC/SNAP)
Encapsulation
AAL5
CS
SAR
Sub-layer
GFC
4 bits
LLC
3 bytes
CS-SDU Info Field
Payload
48 bytes
VPI
VCI
8 bits
16 bits
OUT
3 bytes
PTI
3 bits
IP HeaderPayload
PID
2 bytes
Payload
48 bytes
CLP
HEC
1 bit
8 bits
IP Packet
Padding
0-47 bytesUU1 byte
ATM Header
(5 bytes)
1.3.2Frame and PDU Length vs. IP Packet Length
Figure 2 shows the relationship between IP Packet Length (X axis), Ethernet Frame Length, and
AAL5 PDU length (Y axis). Packet lengths 20 - 128 bytes are shown to illustrate 1-, 2-, and 3-cell
PDUs. The same pattern continues through the maximum Ethernet MTU size - the 1500 byte
packet, which requires 32 cells. There are a few important items to notice on this graph:
Length
CPI
2 bytes
1 byte
48 bytes
ATM Cell
Cells from other VCs
can be interleaved with
cells from this VC
4 bytes
Payload
CRC
ATM to
Ethernet
A8921-01
• 1.The smallest possible Ethernet frame is 64-bytes, which includes the IP packet in addition to
a 14-byte Ethernet header and 4-byte FCS. Adding an 8-byte preamble and 12-byte interframe
gap (960ns) to this frame increases it’s wire-occupancy time to 84 bytes. After IP packet length
exceeds 46 bytes, Ethernet frame length is a linear function of IP packet length.
• AAL5 PDU length is a step-wise function of IP packet length, due to rounding up to ATM cell
boundaries. At 53 bytes per cell, the 4-byte ATM header and 1 byte HEC are included here, but
the physical layer SONET overhead is not shown.
• The smallest possible IP packet, 20 bytes, corresponds to an IP header that does not contain an
IP payload. This packet fits into a single cell PDU, as do packets up to size 32 bytes (20 byte
IP header plus 12 paylo ad bytes).
• Minimized TCP/IP packets are 40 bytes - 20 byte IP header, 20 byte TCP header, and 0 TCP
payload bytes. These "40 byte packets" require 2 cell PDUs - they do not fit into single cell
Application Note9
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
PDUs because 8-bytes of LLC/SNAP plus 8 bytes of AAL5 trailer pu sh them over the 48 byte
payload capacity of a single ATM cell.
• Fully populated 64-byte minimum-sized Ethernet frames carry 46-byte IP packets, and also fit
into 2 cell PDUs, as do IP packets up through 80 bytes.
Figure 2. Frame and PDU Length vs. IP Packet Length
1.3.3Expected Ethernet Transmit Bandwidth
This example design has more Ethernet transmit wire capacity than most full-bandwidth ATM
input workloads is able to consume. All configurations of this example design include more
Ethernet bandwidth than ATM bandwidth. This assures that Ethernet reception is fast enough to
supply ATM transmit at full wire rate, and that Ethernet can transmit fast enough to consume A TM
receive at full wire rate.
When Ethernet receive bandwidth exceeds ATM transmit wire-rate, the design discards the excess
Ethernet input. In the reverse direction, ATM receive wire-rate is less than Ethernet transmit wirerate, and so Ethernet transmit will never be fully consumed.
Given that the design receives cells at OC-3 or OC-12 wire-rate, Figure 3 shows the expected
Ethernet Transmit bandwidth. This pattern is a direct result of the minimum Ethernet frame size
and cell granularity of AAL5 shown in the previous figure. For exampl e, a 32-byte IP packet would
completely fill one cell, and when forwarded to Ethernet, Ethernet it expands to consume the entire
84-bytes of wire-time associated with a 64-byte minimum size Ethernet frame. In this scenario
ATM is more Mbps efficient than Ethernet, 949 Mbps Ethernet output would be expected.
However, as only 800Mbps of Ethernet bandwidth is available, the one-cell PDU workload will
drive the Ethernet wires to their 800Mbps capacity and discard the last 149Mbps.
10Application Note
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
A 33-byte IP packet overflows into 2 cells, requiring 53 more bytes on the input wire. This
effectively slows down the input rate, and the theoretical best-case Ethernet Transmit bandwidth
for this input drops to 475Mbps, well within the capacity of the 8 100Mbps Ethernet ports. Indeed,
only in the one-cell/PDU case does the Ethernet transmit bandwidth requirement exceed the
800Mbps available.
As packets grow larger , the n et ef fect of over flowing to the next cell is smaller. However, the peaks
in maximum bandwidth are also lower, reflecting the additional ATM header that is needed for
each additional cell in the PDU.
The following figure identifies the expected aggr egate Ethernet tran smit bandwid th for ATM OC-3
and OC-12 wire-rate input:
Figure 3. Expected Ethernet Transmit Bandwidth
1.4Execution Environment
1.4.1Software
The software execution environment supported by the Developer’s Workbench is described in the README.txt file that accompanies the source code files for the project. This includes descriptions
of the directory and file structure, and project reconfiguration instructions. See Section 5.0 for
additional information on configuring the project.
The software simulation of the example design consumes test data streams from the Data Stream
feature of the Developer’s Workbench or through a network simulator Dynamic Linked Library
(DLL). Sample Ethernet and ATM data streams are provided.
Application Note11
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
Figure 4 shows how data stream PDUs can be created in the Workbench for ATM, Ethernet, IP, and
other protocol data streams. These data streams can then be assigned to feed different ports. To test
how the example design performs IP routing, different destination IP addresses can be chosen in
the PDU.
Figure 4. Developer’s Workbench - ATM Data Stream Dialog Box
Figure 5 shows the IX Bus Device Status window. This window gives a continually updated
snapshot of IX Bus activity. It can be used to gain an overall picture of what data is being
transferred over the IX Bus "on-the-fly", and the data or wire transmission rate. The Data
Streaming feature and the IX Bus Device Status window are both documented in the IXP1200
Development Tools User’s Guide.
In the simulation environment, the IP and ATM VC table management software that normally run
on the StrongARM core are emulated with a combination of Transactor (simulator) foreign mode ls
and interpreted Transactor scripts.
12Application Note
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
.
Figure 5. Developer’s Workbench - IX Bus Device Status Window
1.4.2Hardware
The README.txt file contained in the vxworks subdirectory of the project source code describes
how to build and run the project on h ardware using VxWorks
simulation mode by default, some simple changes to the project configuration must be made before
it will run on hardware. To run on hardware, Tornado 2.1
Workbench 2.01 need to be installed on the host system. Further details may be found in the
README.txt file in the vxworks subdirectory.
2.0System Overview
2.1System Programming Model
Figure 6 shows the system hardware, as seen by the software. Data flows from the receive p orts on
the left, through the IXP12xx’s RFIFO and its various hardware resources, and then to the TFIFO
and out the transmit ports on the right. ( While logically indepe nden t, receive and tran sm it po rts for
each interface are implemented in the same physical hardware package. The figure uses a single
block arrow to illustrate 1-4 AT M por ts, and 1 -8 Ethernet por ts, d epending on the configuration.)
®
. While the project runs in
®
as well as the IXP1200 Developer’s
Application Note13
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
The StrongARM core shares access to SRAM and DRAM with the microengines, and thus can
manage the VC and IP tables. The StrongARM core runs a Developer’s Workbench debug library
to connect to Developer’s Workbench running on a remote ho st t o debu g an d download microcode.
Figure 6. System Programming Model
2.2StrongARM Core Software
In this example implementation, the StrongARM core runs VxWorks, and initializes the hardware;
controls the baseboard 82559 PCI Ethernet NIC; runs the IXP1200 Developer's Workbench debug
library, and connects it to a remote system host via the PCI Ethernet NIC; runs various startup
utilities (including atm_init() to initialize the IP route and VC Lookup tables) and provides those
utilities for run-time; and runs an agent to consume exception packets which are not handled by the
microengines in the data plane.
In the simulation environment, the IP and VC table management software are emulated with
Transactor foreign models - DLLs which are linked into the Transactor. The same source code is
compiled into the Transactor foreign models for SIMULATION, and th e VxWorks utilities to run
on HARDWARE.
14Application Note
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
2.3Software Partitioning
The following figures show how the microcode functional blocks are partitioned on IXP12xx
hardware for the three system configurations.
Figure 7. IXP1240 1xATM OC-12 and 8xEthernet 100Mbps Microengine Partitioning
Ethernet TX
Ethernet RX
Ethernet
Ethernet
Ethernet
Ethernet
Scheduler
Fill
Fill
Fill
Port0
Port1
Port2
Port3
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
A9634-01
OC-12 Port
OC-12 Port
Legend:
= Thread
= Microengine
= Physical Port
ATM RX
Port 8
Port 8
Port 8
Port 8
ATM TX
Fill
Fill
Fill
Unused
MSGQ
MSGQ
= Scratchpad
Memory
= SRAM
IPR
IP Route
IP Route
IP Route
IP Route
MSGQ
Ethernet RX
Port4
Port5
Port6
Port7
= MSGQ
PktQ
PktQ
PktQ
PktQ
PktQ
PktQ
PktQ
PktQ
All three figures show the ATM ports on the left, and the Ethernet ports on the right. All ports are
bi-directional, but are shown as uni-directional for clarity. The IX bus is configured in dual 32 bit
unidirectional mode.
The ATM Receive microengine uses the SRAM VC Lookup Table to assemble ATM cells into
AAL5 PDUs in DRAM. It forwards the descriptor to the fully-assembled PDUs to the IP Route
microengine via a single message queue (MSGQ) in scratchpad RAM.
The IP Route microengine reads the IP header from DRAM, performs additional checks per
RFC1812, performs an IP lookup to make a routing decision, then enqueues the Ethernet frame to
the appropriate Ethernet Transmit packet queue. In the Software CRC configuration, the packet is
processed by a CRC-32 checking microengine before being enqueued to an Ethernet transmit
packet.
In the reverse direction, Ethernet frames are received on the Ethernet ports by the Ethernet receive
microengine(s), which perform IP lookup and RFC1812 check s. The packets are then enqueued on
the appropriate queues to be consumed by the ATM transmit microengine. In the software CRC
configuration Figure 9, the PDUs are first processed by a CRC generation microengine before
going to the ATM Transmit microengine.
Application Note15
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
In the OC-12 configuration, there are two message queues (MSGQs) in scratchpad RAM, one for
PDUs from each Ethernet Receive microengine. The pool of threads in the ATM transmit
microengine alternately poll the two MSGQs.
In the OC-3 configurations, there is a buffer descriptor queue (BDQ) in SRAM associated with
each ATM transmit port. BDQs are similar to packetqs, but they are slightly more efficient in
configurations, where for example the transmitter dedicates a thread to each BDQ.
Figure 8. IXP1240 OC-3 4xATM and 8xEthernet 100Mbps Microengine Partitioning
Ethernet TX
Scheduler
Fill
Fill
Fill
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
OC-3
OC-3
OC-3
OC-3
ATM RX
Port 8
Port 9
Port 10
Port 11
MSGQ
IPR
IP Route
IP Route
IP Route
IP Route
PktQ
PktQ
PktQ
PktQ
PktQ
PktQ
PktQ
PktQ
ATM TX
OC-3
OC-3
OC-3
OC-3
Legend:
= Thread
= Microengine
= Physical Port
Port 8
Port 9
Port 10
Port 11
2.3.1Lookup Tables
Not shown in the diagrams, the microengines make use of either three or four lookup tables:
• VC Lookup Table - resides in SRAM and is used by the ATM Receive microengine.
• IP Lookup Table - resides partially in SRAM and partially in DRAM, and is used by the IP
Route microengine and the Ethernet Receive microengine.
• MAC Address Hash Table - resides in SRAM and is used for RFC 1812 Port address
verification.
• Software CRC configurations use a table of pre-computed CRC-32 syndromes in SRAM.
BDQ
BDQ
BDQ
BDQ
= Scratchpad
Memory
= SRAM
Ethernet RX
Port4
Port5
Port6
Port7
= MSGQ
Ethernet RX
Ethernet
Ethernet
Ethernet
Ethernet
Port0
Port1
Port2
Port3
Ethernet
Ethernet
Ethernet
Ethernet
16Application Note
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
Figure 9. IXP1200 2xATM OC-3 Software-CRC and 4xEthernet 100Mbps Microengine
Partitioning
ATM RX
OC-3
OC-3
OC-3
OC-3
Legend:
= Thread
= Microengine
= Physical Port
Port 8
Port 9
IP Route
IP Route
ATM TX
Port 8
Port 9
Unused
Unused
MSGQ
BDQ
BDQ
= Scratchpad
Memory
= SRAM
2.4Data Flow
2.4.1ATM to Ethernet Data Flow
*
CRC CHK
Check
Check
Check
Check
CRC GEN
Generate
Generate
Generate
Generate
= MSGQ
PktQ
PktQ
PktQ
PktQ
MSGQ
Ethernet TX
Scheduler
Fill
Fill
Fill
Ethernet RX
Port0
Port1
Port2
Port3
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
Ethernet
A9636-01
Figure 10 outlines th e processing to receive ATM cells and forward them to Ethernet ports. For a
given VC, three different types of cells of the PDU can arrive: the first cell, middle cells, and last
cell:
1. The first cell of the IP over ATM PDU contains three types of headers: ATM header, LLC/
SNAP header, and IP Header. This is sufficient information to make a forwarding decision.
The payload portion of this cell is moved directly from the RFIFO to DRAM.
2. Subsequent middle cells are moved directly from the RFIFO to DRAM without any additional
processing.
3. When the last cell of th e PDU (which contains the AAL5 trailer) is receiv ed, the payload of the
cell is moved directly from the RFIFO to DRAM, and the completed PDU is then enqueued
for Ethernet transmi s sion.
2.4.1.1VC Lookup
A VC lookup is performed on each cell received over an ATM port. The appropriate VC Table
Entry is located using the VPI/VCI value in the ATM header plus the port number. The lookup
provides an DRAM packet buffer base address, plus the CRC-32 syndrome for the PDU. As each
additional payload is added to the DRAM buffer, the offset value is incremented and the CRC
Application Note17
Modified on: 3/20/02,
IXP1200 Network Processor Family ATM OC-3/12/Ethernet IP Router Example Design
syndrome is updated appropriately. The VC Table Entry also contains an AAL type field.
Currently, this example design supports only classical IP over ATM, where the AAL type can be
either 0 or 5. A value of 0 indicates that the VC is not open, so any cell received on that VC is
immediately discarded.
The LLC/SNAP field specifies the protocol type. Currently, the only valid value is 0x AA AA 03
00 00 00 08 00 (classical IP over ATM). While this implementation consumes and produces just
one valid LLC/SNAP pattern, this pattern is not hard-coded. The LLC/SNAP bits are included in
the IP route table entry, as well as the VC lookup table. This is to make it easy to modify the design,
not only support a different LLC/SNAP pattern, but also to be able to support different valid
patterns for each VC.
2.4.1.2IP Lookup Ta ble
Each PDU contains an IP header in its first cell. Therefore, a single IP lookup is performed for each
PDU, regardless of the number of cells in the PDU.
Figure 10. ATM to Ethernet Processing Steps
ATM PDU on Rx Port
1
Receive
ATM Cell
LLC
ATM
Hdr
Hdr
IP
Payload
Hdr
VC Look-up check
LLC/SNAP header
on first cell
ATM
Hdr
If end of PDU
6
Check
length
8
Strip
AAL-5
trailer
IP
Lookup
Address
2
3
IP
VC Lookup Table Entry
VPI/VCI
CRC
LENCLPPADUU
7
Check
CRC
IP look-up
on first cell
Route Table
Port
Port
number
type
AAL
LLC/SNAP
type
header
Move
payload
to buffer
header
Packet Buffer
5
Enet
Buffer
offset
SDRAM
Cell N
(40 Bytes)
Cell 1
(48 Bytes)
Cell 0
(48 Bytes)
Locate buffer & offset
4
Buffer base
address
Check CRC
on AAL-5 PDU
7
Ethernet PDU on Tx Port
Transmit
MPKT
Ether
Hdr
IP Payload
Build MPKT,
9
add Ethernet
header on first
MPKT
CRC-32
Residue
10
A9638-01
18Application Note
Modified on: 3/20/02,
Loading...
+ 40 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.