Digital Subscriber Line Access Multiplexer (DSLAM) Example Design

Digital Subscriber Line Access 

Multiplexer (DSLAM) 

Example Design 

Application Note 

May 2002 

Order Number: 251070-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 Digital Subscriber Line Access Multiplexer (DSLAM) Example Design 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. 

This document and the software described in it are furnished under license and may only be used or copied in accordance with the terms of the 

license. The information in this document 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. 

Copyright © Intel Corporation, 2002 

*Other names and brands may be claimed as the property of others.

Contents 

Contents 

1.0 Introduction ...............................................................................................................................5 

1.1 Purpose of DSLAM Example Design....................................................................................5 

1.2 Scope of Example Design ....................................................................................................5 

1.3 Execution Environment.........................................................................................................6 

1.3.1 Software...................................................................................................................6 

1.3.2 Hardware .................................................................................................................6 

2.0 System Overview.....................................................................................................................7 

2.1 Software Partitioning.............................................................................................................8 

2.2 Dual Chip Data Flow...........................................................................................................10 

2.3 StrongARM Core Initialization.............................................................................................13 

2.4 Microengine Initialization ....................................................................................................13 

3.0 Microengine Functional Blocks.......................................................................................14 

3.1 Receive Microblock Group..................................................................................................14 

3.1.1 Initialization Microblock..........................................................................................15 

3.1.2 Ingress Microblock.................................................................................................15 

3.1.3 Transform Microblock ............................................................................................16 

3.1.4 Egress Microblock .................................................................................................17 

3.2 Receive Processor Transmit Microblock Group .................................................................19 

3.3 Transmit Processor Receive Microblock Group .................................................................20 

3.3.1 Initialization Microblock..........................................................................................20 

3.3.2 Ingress Microblock.................................................................................................20 

3.3.3 Transform Microblocks...........................................................................................21 

3.3.4 Egress Microblock .................................................................................................21 

3.4 Transmit Processor Traffic Scheduler ................................................................................21 

3.5 Transmit Processor Traffic Shaper .....................................................................................22 

3.6 Transmit Processor Traffic Transmit...................................................................................22 

4.0 Data and Tables......................................................................................................................22 

4.1 Receive Processor..............................................................................................................22 

4.1.1 Input Data ..............................................................................................................22 

4.1.2 Output Data ...........................................................................................................26 

4.2 Transmit Processor.............................................................................................................28 

4.2.1 Input Data ..............................................................................................................28 

4.2.2 Output Data ...........................................................................................................29 

4.3 Connection, Routing, and Hash Tables ..............................................................................29 

4.3.1 Rate Manager ........................................................................................................30 

4.3.1.1 Port Table Entry .....................................................................................30 

4.3.1.2 VC Table Entry.......................................................................................31 

5.0 Project Configuration / Modifying the Example Design ........................................32 

6.0 Testing Environment............................................................................................................32 

7.0 Simulation Support (Scripts, etc.) ..................................................................................32 

7.1 Simulation for the Receive Processor Project ....................................................................32 

Application Note

Contents 

7.1.1 Initialization Scripts ................................................................................................ 32 

7.1.2 Test Case Scripts .................................................................................................. 33 

7.2 Simulation for the Transmit Processor Project ................................................................... 34 

7.2.1 Initialization Scripts ................................................................................................ 34 


7.3 Simulation for the Receive/Transmit Processor Project ..................................................... 36 

7.3.1 Initialization Script.................................................................................................. 36 


8.0 Performance ............................................................................................................................ 37 

9.0 Limitations ............................................................................................................................... 37 

10.0 Extending the Example Design ....................................................................................... 38 

11.0 Acronyms & Definitions...................................................................................................... 39 

12.0 Reference Documents .........................................................................................................40 

Figures 

1 System Overview.......................................................................................................................... 7 

2 Receive Processor System Partitioning ....................................................................................... 8 

3 Transmit Processor System Partitioning ...................................................................................... 9 

4 Receive Processor Data Flow for ATM AAL5 PDUs ..................................................................10 

5 Receive Processor Data Flow for Flow Control Packets ............................................................11 

6 Transmit Processor Data Flow for PDUs and Flow Control ....................................................... 12 

7 Receive Processor Receive Microblock Group Data Flow ......................................................... 14 

8 Receive Processor Transmit Microblock Group .........................................................................19 

9 Transmit Processor Receive Microblock Group .........................................................................20 

10 Receive Processor Input - Routed IP over ATM with DSLAM Header ....................................... 24 

11 Receive Processor Input - Bridged Ethernet over ATM with DSLAM Headers .......................... 25 

12 Receive Processor Input - Flow Control Packet with DSLAM Header ....................................... 26 

13 Receive Processor Output to IXB3208....................................................................................... 27 

14 Inter-IXP Header Format ............................................................................................................ 27 

15 Transmit Processor Input from IXB3208 .................................................................................... 28 

16 Transmit Processor Output.........................................................................................................29 

Tables 

1 L3 Routing Table - IP Route Example ........................................................................................ 30 

2 Test Case Descriptions and their Files....................................................................................... 33 

3 Test Case Descriptions and their Network Traffic dlls................................................................ 35 

4 Test Case Descriptions and their Stream Files .......................................................................... 35 

5 Test Case Descriptions and their Files....................................................................................... 37 

Application Note

Digital Subscriber Line Access Multiplexer (DSLAM) Example Design 

1.0 Introduction 

Intel develops software example designs to demonstrate the capabilities of the IXP Network 

Processor Family. This document describes the implementation of example software demonstrating 

the IXP1240 in a Digital Subscriber Line Access Multiplexer (DSLAM) environment. In 

particular, this example design uses the IXP1200 to route IP packets between ATM and a DSL 

Aggregator. 

This document serves as a companion to the comments in the source code, and is intended to 

clarify the structure and general workings of the design. The following material is covered: scope 

of the design; code structure and flow; data structures; inter-process signaling; initialization and 

startup; software and hardware execution environments; etc. At the end of this document, a list of 

acronyms and definitions, as well as a list of related documents are provided. 

The README.TXT bundled with the software should be consulted for instructions on running the 

project, building the code, and the actual layout of the source files. 

1.1 Purpose of DSLAM Example Design 

This example design is intended as a starting point for customers designing similar applications. It 

is also intended for customers to get an idea of what the IXP1200 Network Processor is capable of, 

and what kind of performance can be expected. Users may modify the code, adding additional 

modules that are proprietary or more specific to their needs, and estimate performance. 

This Example Design demonstrates just one software architecture in which the IXP1200 can be 

used in DSLAM-related designs. It should be noted that this design is just a starting point, and not 

intended to be ’production ready’. 

1.2 Scope of Example Design 

This design addresses the following: 

• The completed IXP1200 microcode and micro-C shall run on the simulator in the IXP1200 

Developer WorkBench (DWB) using the IXP1240 chip setting. 

• Two-IXP1240-Processor Design (using an IXB3208 as an interconnection device) 

• One OC-12 port input, one OC-12 port output 

• Segmentation and Re-assembly (SAR) 

• ATM Adaptation Layer 5 

• IP over ATM LLC/SNAP Encapsulation (RFC 1483) 

• Routing between ATM and DSL based on IP, supporting both Longest Prefix Match and 

FiveTuple lookup methods 

• Constant Bit Rate (CBR), Variable Bit Rate (VBR), and Unspecified Bit Rate (UBR) 

• Support for up to 4096 Virtual Channels (VC) 

• Flow Control 

• Use of “microblock” architecture (Receive Processor) 

• Use of Micro-C Compiler (Transmit Processor only) 

Application Note 5


• Static Route Table Manager 

• Rate Manager .dll 

The following are not addressed: 

• Ethernet and Frame Relay processing 

• ATM ARP 

• ATM signaling 

• TM4.1 compliance (Transmit Processor) 

Receive Processor software is written using microcode in microblock architecture while Transmit 

Processor software is written in microengine C using microblock architecture. 

1.3 Execution Environment 

1.3.1 Software 

1.3.2 Hardware 

The software execution environment supported by the Developer’s Workbench is described in the 

Processor_2ixp_README.txt file that accompanies the source code files for the project (DSLAM 

directory). This includes descriptions of the directory and file structure, and also how the project 

can be re-configured. 

The software simulation of the example design is fed test data streams via the NetworkTraffic DLL 

and the NetSim DLL. 

In the simulation environment, the IP and ATM VC table management software are emulated with 

a combination of Transactor (simulator) foreign models and interpreted Transactor scripts. 

The example design was not supported on hardware at the time of the release of this document. 

6 Application Note


2.0 System Overview 

Figure 1 illustrates the steps for moving an IP packet from the ATM/DSL Aggregator to the output 

of the Transmit Processor. 

Figure 1. System Overview 

Intel ® Pentium ® 

Processor 

PCI Bus 

Intel ® IXP1200 

"Receive 

Processor" 

Reassembly 

Validation 

IP Lookup 

Protocol Translation 

Classification 

Intel ® IX Bus 

Intel ® IXB3208 

Network 

Processor 

Intel IX Bus 

Intel IXP1200 

"Transmit 

Processor" 

Traffic Management 

Segmentation 

Transmission 

Incoming 

"DSLAM ATM" 

Traffic 

Outgoing 

"DSLAM ATM" 

Traffic 

Customer-provided 

ATM/DSL Aggregator 

ATM 

DSL 

A9550-01 

On the data path in the Receive Processor, IP over ATM traffic (coming from the ATM/DSL 

aggregator over the ATM port) is processed and transmitted over the IX bus as a pre-classified 

AAL5 PDU segmented for IXB3208 consumption. The receiving threads receive ATM cells with 

prepended DSLAM headers, perform reassembly of the ATM PDU, and extract the IP packet 

according to the AAL5 and LLC/SNAP specified in a VC connection table. 

Upon reception of a complete AAL5 PDU, the receiving threads (if so configured) use the 

hardware CRC capability of the IXP1240 to perform the CRC-32 checks necessary for AAL5. The 

receiving threads perform an IP lookup and any required IP header transformation, prepend an 

inter-IXP header containing classification data, and then queue the PDU to the transmit thread. 

Application Note 7


On the data path in the Transmit Processor, 64-byte segmented chunks of data are received from 

the IXB3208. They are reassembled into full PDUs, which already include padding and an AAL5 

trailer. The PDUs are then scheduled and shaped according to their contract, segmented and then 

transmitted back out to the DSLAM aggregator. 

2.1 Software Partitioning 

Figure 2 shows how the design is partitioned between IXP1200 microengines in the Receive 

Processor. There are four dedicated microengines receiving incoming DSLAM traffic, one 

microengine transmitting to the IXB3208, and one spare microengine (not shown). 

One ATM port, shown on the left side of the diagram supplies DSLAM cells to the receiving 

microengines. They are assembled into PDUs or flow control packets, validation, IP lookups, and 

header transformations are performed, and the resulting PDUs or flow control packets are queued 

to the transmitting microengine. The transmitting microengine then segments the frames into 64- 

byte chunks and transmits them to the IXB3208. 

Figure 2. Receive Processor System Partitioning 

Microengine 

0 

RFIFO 

Microengine 

1 

Microengine 

2 

SDRAM 

Buffers 

Microengine 

5 

4 Transmitting threads 

running on 1 Microengine 

TFIFO 

Microengine 

3 

16 Receiving threads 

running on 4 Microengines 

A9548-01 

8 Application Note


Figure 3 shows how the design is partitioned between IXP1240 microengines in the Transmit 

Processor. There are two microengines dedicated to receiving incoming pre-classified ATM traffic 

from the Receive Processor via the IXB3208, and four microengines dedicated to shaping, 

scheduling and transmitting. 

Figure 3. Transmit Processor System Partitioning 

Microengine 

2 

RFIFO 

Microengine 

0 

Microengine 

1 

SDRAM 

Buffers 

Microengine 

3 

Microengine 

4 

TFIFO 

8 Receiving Threads 

running on 2 Microengines 

Microengine 

5 

8 Scheduler and 

8 Shaping/ Threads 

transmitting on 4 Microengines 

On Microengines 2-5: Contexts 0, 2 

Scheduler Contexts 1, 3: Shaper/Transmit 

A9549-02 

One IX bus port, shown on the left side of the diagram, supplies DSLAM IXB3208 segments to the 

receiving microengines. They are assembled into PDUs or flow control packets, and the Inter-IXP 

header for each is extracted and saved. PDUs are sent to the appropriate scheduler/shaper 

microengines (determined by the wheel number assigned to that microengine) via message queues. 

Flow control packets are used by the receiving threads to start or to stop transmission to particular 

ports. Based on the bit-rate contract for each particular VC and destination port, PDUs are 

scheduled, segmented, prepended with DSLAM headers, and transmitted. 

Application Note 9


2.2 Dual Chip Data Flow 

Figure 4 illustrates what steps are necessary to move an IP packet from the ATM/DSL Aggregator 

to the output of the Receive Processor, which goes to the IXB3208. 

Figure 4. Receive Processor Data Flow for ATM AAL5 PDUs 

DSLAM / ATM PDU on Rx Port 

(and subsequently in the RFIFO) 

Note: Only steps 1 through 4 

are performed for middle 

cells in the PDU 

1 

Receive 

DSLAM 

ATM 

Cell 


HDR 

ATM 

HDR 

If last cell in PDU 

PAD CLP 

UU LEN CRC 


HDR 

ATM 

HDR 

If first cell in PDU 

LLC 

HDR 

IP 

HDR 

TCP 

HDR 

Payload 

9 

Check AAL5 

Trailer (length 

and checksum) 

2 

Look up 

VC (using 

hash) 

5 

Validate AAL5 

and IP Headers 

4 

Move cell payload 

to buffer 

SDRAM 

Packet Buffer 

Used for 

computing new 

header 

(32 bytes) 

Cell 0 

(48 Bytes) 

Cell 1 

(48 Bytes) 

Cell N 

(48 Bytes) 

7 

Create 

new header 

in buffer 

Connection Table 

VP/VC/Physical 

Port Number 

6 

Look up route and 

header on first cell 

Route Table 

Destination 

IP/IP Port 

Connection 

Status 

Bit 

Rate 

Network 

Model 

Queue 

ID 

Header 

Info 

Destination 

Port / VC 

8 

Update with new 

header info 

Buffer 

Base 

AAL5 

Header 

Buffer 

Offset 

3 

Locate buffer and offset 

10 

Transmit in 64-byte segments with prepended 

Intel® IXB3208 Network Processor headers 

A9559-01 

10 Application Note


Figure 5 illustrates what steps are necessary to move a flow control packet from the ATM DSL 

Aggregator to the output of the Receive Processor, which goes to the IXB3208. 

Figure 5. Receive Processor Data Flow for Flow Control Packets 

DSLAM Flow Control Packet on Rx Port 


1 

Receive DSLAM 

Flow Control 

Packet 


HDR 

Payload 

2 

Allocate new buffer 

in SDRAM 

SDRAM 

Packet Buffer 

Flow 

Control 

Packet 

3 

Move payload to buffer 

4 

Transmit in 64-byte segments with prepended 

Intel® IXB3208 Network Processor and 

Inter-IXP headers 

A9560-01 

On the data path in the Receive Processor, flow control packets coming from the ATM/DSL 

Aggregator over the ATM port are transmitted over the IX bus with an appropriate Inter-IXP 

header and segmented for IXB3208 consumption. No transformation is performed on flow control 

packets in the Receive Processor. 

Application Note 11


Figure 6 illustrates what steps are necessary to move IP packets and flow control packets from the 

IXB3208 input to the Transmit Processor to the ATM port. 

Figure 6. Transmit Processor Data Flow for PDUs and Flow Control 

Pre-classified DSLAM / ATM PDU on Rx Port 


1 

Receive 

Intel® 

IXB3208 

segment 

Note: Only steps 1 and 3 are 

conducted for middle 

segments in the PDU 

If last 64-byte or partial 64-byte 

segment in PDU (if EOP is true) 

Payload 

If first 64-byte segment in PDU 

(if SOP is true) 

Inter-IXP 

Header 

Payload 

4 

Move segment 

payload to buffer 

2 

Store Inter-IXP 

header in thread 

mailbox 

3 

Move segment 

payload to buffer 

SDRAM 

Packet Buffer 

Segment 0 

(64 bytes) 

Segment 1 

(64 bytes) 

Segment 2 

(64 bytes) 

Thread Mailbox 

(contains Inter-IXP header) 

Queue for 

Traffic Management 

5 

Retrieve Inter-IXP 

header and queue 

to traffic management 

Segment n 

(64 bytes or less) 

6 

OR 

If PDU, Traffic Management 

schedules, shapes and transmits 

AAL5 PDU as ATM cells with DSLAM 

header per the contract specified in 

the Inter-IXP header 

7 

If flow control, Receive code blocks 

or unblocks transmission based on 

port and flow ID in Inter-IXP header. 

A9562-01 

In the Transmit Processor, data is received from the IXB3208 in 64-byte (or less) segments. The 

last segment may not be 64 bytes, depending on the length of the PDU or flow control packet. The 

first segment contains the Inter-IXP header attached by the Receive Processor. This header 

contains information that classifies the packet: 

• Data or Flow Control 

• Protocol (ATM or other) 

• Unicast or Multicast 

12 Application Note


• The bit rate at which the data should be sent (CBR/VBR/UBR) 

• The UBR Priority 

• Time spent in Receive Processor 

• Packet Size 

• Queue ID, Output Port, and VC 

The packet is stored in SDRAM. The Inter-IXP header is saved to a mailbox in scratch memory 

until the entire packet is received, and then it is queued to the traffic management software. The 

traffic management software uses information from the Inter-IXP header, vc table, and port table 

for scheduling, shaping, and transmission of the packet stored in SDRAM. Information regarding 

the traffic management software design may be found on page 42 of the DSLAM Router/Traffic 

Shaper Software Design Specification White Paper. 

2.3 StrongARM Core Initialization 

Before starting the microengines, the Receive Processor StrongARM Core initializes the IP 

Lookup (Routing) Table, and the VP/VC Lookup (Connection) Table. It also initializes the Buffer 

Descriptor Freelist. On the Transmit Processor, the StrongARM Core initializes the Rate Manager 

(see Section 4.3.1). 

In the simulation environment, this is done by code invoked from the Transactor startup scripts 

dslam_proc_a.ind and dslam_proc_b.ind. The IP and VC table management software are emulated 

with a combination of Transactor foreign models and interpreted Transactor scripts. 

2.4 Microengine Initialization 

In the Receive Processor, the initialization code of the transmit microblock group on Microengine 

5, thread 0, performs most of the initialization for the Receive Processor in general. It also signals 

the appropriate threads on Microengines 0-3, which start the receive microblock group. In the 

Transmit Processor, dslam_uc_init and dslam_system_init initialize the entire application. 

Application Note 13


3.0 Microengine Functional Blocks 

3.1 Receive Microblock Group 

Figure 7 shows the data flow for the transmit microblock group in the Receive Processor. This flow 

also represents the dispatch loop used to control the microblock group. 

Figure 7. Receive Processor Receive Microblock Group Data Flow 

IP Header 

outgoing_pkt 

Intel ® SA 

Core 

IXPA RFIFO 

FIFO_Addr 

+ 

LLC_1483_Type 

Process 

Data 

Cell 

outgoing_pkt 

OR 

IXPA RFIFO 

Initialization 

mpkt_descriptor, 

incoming_cell_payload, 

fifo_addr 

incoming_control_pkt, 

next_thread_id, 

canned_rev_request 

canned_rcv_request, 

fifo_addr 

Receive 

Cell 

sdram_buf_offset, 

connection_index, 

net_model, 

connection_entry, 

fifo_addr, 

bd_address 

control_pkt_ptr, 

bd_address 

Process 

Control 

Packet 

outgoing_control_pkt 

pdu 

buffer 

A9551-01 

14 Application Note


3.1.1 Initialization Microblock 

The following macro header describes the initialization microblock for the Receive Processor 

microblock group and is contained in the file 

$Gen_DSLAM\hyannis\microblocks\dslam_rx_ublock_group_a.uc. 

// DSLAM_Initialize_Receive_uBlock_Group_A 

// 

// Description: 

// This macro performs initialization for the Receive uBlock group 

// in the Receive Processor of the Generic DSLAM application. 

// 

// Inputs: 

// next_thread_id next thread to signal when complete 

// canned_receive_request fixed receive request for FIFO 

// rfifo_address RFIFO location from which to read 

// @request_inflight critical section for accessing FIFO 

// 

// Macros defined: 

// DESC_SIZE 

// PKBUF_SIZE 

// PORT_NUMS 

// NEXT_CTX0_TID 




// CORE_STACK_INTF1 

// 

// Implementation: 

// Initialize all the input parameters, and send appropriate signals 

// to prepare for packet processing. 

// 

// Size: 

// 48 instructions 

// 

// Example usage: 

// .local next_tid, rcv_req, fifo_addr 

// immed[@req_inflight,0] 

// DSLAM_Initialize_Receive_uBlock_Group_A(next_tid, rcv_req, fifo_addr, 

// @req_inflight) 

// 

3.1.2 Ingress Microblock 

The following macro header describes the ingress microblock for receiving incoming PDUs and 

flow control packets. It is contained in the file 

$Gen_DSLAM\hyannis\microblocks\dslam_rx_ublock_group_a.uc. 

// DSLAM_Receive 

// 


// This is the ingress ublock for DSLAM Receive Processing uBlock 

// for IXP1200 Receive Processor. 

// Issues a receive request to the RFIFO, parses and stores various 

// portions of the packet descriptor, looks up the connection entry 

// in the connection table based on the physical port number, vpi, 

// and vci, and reads packet data from RFIFO and stores it in SDRAM. 

// CRC may be computed when reading from the RFIFO if enabled. 

// 

// Inputs: 

// return_status success or failure 

// next_thread_id used to signal next thread to issue receive 

Application Note 15


// request (canned) 

// receive_request receive request to be issued (canned) 

// @request_inflight critical section for accessing FIFO 

// buffer_descriptor_address address for buffer descriptor in SRAM 

// sdram_buffer_address address for buffer in SDRAM 

// sdram_buffer_offset offset into buffer in SDRAM 

// pdu_completion indication that last part of PDU has been 

// received 

// rfifo_address address of data packet in RFIFO 

// physical_port_type ATM, Ethernet, Frame Relay, etc. 

// connection_entry_address index of connection entry 

// network_model type of transformation to perform 

// crc_residue initial crc residue to be updated 

// packet_type packet type, if flow control packets 

// supported 

// 


// If physical port type is ATM, 

// Read from the RFIFO into SDRAM 

// Determine if this is the last part of a PDU 

// Update connection table entry with new buffer offset 

// Else 

// Fail for all unsupported physical port types 

// 

// Size: 

// 247 instructions (w/ CRC, w/o other protocol, w/o flow control support) 

// without CRC, -16 instructions 

// with other protocol support, +38 instructions 

// with flow control support, +16 instructions 

// 


// DSLAM_Receive(status, next_tid, rec_req, @req_inflight, bd_address, 

// buff_sdram, sdram_buff_offset, pdu_complete, fifo_addr, 

// phy_port_type, \ 

// cnx_entry_address, net_model, temp_residue, DSLAM_packet_type) 

// 

3.1.3 Transform Microblock 

The following macro header describes the transform microblock for incoming PDUs. (Flow control 

packets are passed through the Receive Processor and not transformed in any way.) It is contained 

in the file $Gen_DSLAM\hyannis\microblocks\dslam_rx_ublock_group_a.uc. 

// ATM_IP_Route_Lookup_And_Transform 

// 


// This is a transform block that performs an IP route lookup based 

// on the network model, and an IP transform based on the routing 

// information from the lookup operation. 

// 

// Inputs: 

// return_status success or failure 

// network_model type of transformation to perform 

// ip_header_xfer_registers SRAM xfer registers holding IP header 

// llc_1483_encapsulation_type type of 1483 encapsulation in PDU 

// rfifo_address address of data packet in RFIFO 


// sdram_buffer_address address for buffer in SDRAM 

// 


// if network_model is IP_TRIE_LKUP 

// perform a longest-prefix-match IP lookup to get routing pointer 

// else if network model is IP_5TUPLE_LKUP 

// perform a IP 5-tuple lookup to get routing pointer 

16 Application Note


// transform the IP header based on the routing information 

// 

// Size: 


// 


// ATM_IP_Route_Lookup_And_Transform(status, net_model, $ip_header, \ 

// llc_encap_type, fifo_addr, cnx_entry_address, sdram_buff_addr) 

3.1.4 Egress Microblock 

Two egress microblocks are available for the receive microblock group in the Receive Processor: 

• DSLAM_Enqueue (enqueues packets to the transmit microblock group) 

• DSLAM_SA_Enqueue (enqueues exception packets to the StrongARM core) 

The following macro headers describe the egress microblocks for outgoing PDUs and flow control 

packets. They are contained in the file $Gen_DSLAM\hyannis\ 

microblocks\dslam_rx_ublock_group_a.uc. 

// DSLAM_Enqueue 

// 


// This is an egress block that queues either a flow control 

// packet or a PDU to a ring buffer for ingress into the 

// transmit microblock group. 

// 

// Inputs: 

// packet_type type of packet (control or data) (if 

// supporting control packets) 

// pdu_completion whether the PDU is complete, if packet type 

// is data 

// buffer_descriptor_address address for buffer descriptor 

// physical_port_type ATM, Ethernet, Frame Relay, etc. 


// pdu_length length of PDU in buffer 

// 


// if packet_type is control 

// enqueue the flow control packet 

// else 

// enqueue the PDU 

// 

// Size: 

// 61 instructions (without flow control packet support and without other 

// protocol support) 

// with other protocol support, +18 instructions 

// with flow control packet support, +25 instructions 

// 


// DSLAM_Enqueue(pkt_type, pdu_complete, bd_address, phy_port_type, \ 

// cnx_entry_address, length) 

// 

// DSLAM_SA_Enqueue 

// 


// This is an egress block that queues an ATM PDU to the 

// StrongARM core for exception processing. 

// 

// Inputs: 

Application Note 17


// buffer_descriptor_address address for buffer descriptor 

// pdu_length length of PDU in buffer 

// 


// Prepare SRAM xfer registers used for queueing 

// Get the next index for the packet queue 

// Enqueue the PDU using packetq_send 

// 

// Size: 


// 


// DSLAM_SA_Enqueue(bd_address, length) 

18 Application Note


3.2 Receive Processor Transmit Microblock Group 

Figure 8 shows the data flow for the transmit microblock group in the Receive Processor. This flow 


Figure 8. Receive Processor Transmit Microblock Group 

Conditionally compiled depending upon 

Intel ® IXB3208 Network Processor 

Support Definition 

DSLAM_Initialize_ 

Transmit_uBlock_ 

Group_A_IXB3208 

DSLAM_Initialize_ 

Transmit_uBlock_ 

Group_A 

Conditionally 

compiled 

depending upon 

Intel IXB3208 

Network Processor 

Support Definition 

DSLAM_Copy_ 

Enqueue_IXB3208 

outgoing_pkt 

with prepended 

Intel IXB3208 

Header 

constants and sequences 

and 

Initializations of 

DSLAM_ 

Dequeue 

Initializations 

sequences 

constants 

pdu 

of 

pdu 

DSLAM_Copy_ 

Enqueue 

TFIFO 

outgoing_pkt 

pkt 

queue 

outgoing_pkt 

A9552-01 

Application Note 19


3.3 Transmit Processor Receive Microblock Group 

Figure 9 shows the data flow for the receive microblock group in the Transmit Processor. This flow 


Figure 9. Transmit Processor Receive Microblock Group 

First 

Segment 

Processing 

Inter-IXP Header 

RFIFO 

64-byte 

(or less) 

segment 

Issue 

Receive 

Request 

Thread 

Mailbox 

Midsegment 

Processing 

Valid PDU 

Enqueue 

to Shaper/ 

Scheduler 

Last 

segment 

Processing 

A9563-01 

3.3.1 Initialization Microblock 

Initialization is performed just above the beginning of the dispatch loop. Because of inefficiencies 

in passing references in micro-C, this initialization is not encapsulated into its own microblock 

function. 

3.3.2 Ingress Microblock 

The following function header describes the ingress microblock for the receive microblock group 

in the Transmit Processor. This function is contained in the files 

$Gen_DSLAM\hyannis\workbench_projects\dslam_proc_b_uC\main0.c and 

$Gen_DSLAM\hyannis\workbench_projects\dslam_proc_b_uC\main1.c. 

// ************************************************************************ 

// DSLAM_CopyReceive 

// ************************************************************************ 

// 

20 Application Note


// Description:move mpacket to packet buffer and 

// update packet buffer address for next thread 

// 

// Outputs: 

// Now a global : out_exceptionif re-assembly failed, exception will be > 0 

// 

// Inputs/Outputs: 

// Now a global : rec_state mpacket status information 

// Now a global : packet_buf_addr sdram packet buffer address 

// Now a global : buffer_allocation_vector vector variable to keep track of 

which threads have a current buffer popped. 

// 

// Input: 

// my_mb this thread’s mailbox address for updated segment address 

// next_mb next thread’s mailbox address for updated segment address 

// next_tid next thread’s id for signaling 

// rec_req canned receive request for IX Bus 

// rfifo_addressrfifo address this thread will use 

// 

3.3.3 Transform Microblocks 

No transformations are done in the receive microblock group in the Transmit Processor. 

3.3.4 Egress Microblock 

One egress microblock is available for the receive microblock group in the Transmit Processor: 

• DSLAM_CopyEnqueue (enqueue to the traffic management system) 

The following function header describes the egress microblock. This function is contained in the 

files $Gen_DSLAM\hyannis\workbench_projects\dslam_proc_b_uC\main0.c and 

$Gen_DSLAM\hyannis\workbench_projects\dslam_proc_b_uC\main1.c. 

// ************************************************************************ 

// DSLAM_CopyEnqueue 

// ************************************************************************ 

// 


// Get the inter ixp header either from memory, or from the rfifo if sop. 

// Determine if the packet is flow control or data. 

// If flow control, then update the flow control table and set the bit 

// according the vc either on or off. 

// If data, then create a message for the tm41_receive code, and send it. 

// 

// Inputs: 

// Now a global : rec_statempacket status information 

// rfifo_addressrfifo address this thread will use 

// Now a global : packet_buf_addr packet buffer address 

// 

3.4 Transmit Processor Traffic Scheduler 

The TM4.1_Scheduler function schedules cells for transmit based on traffic contract associated 

with a VC. It schedules shaped VCs that have strict time constraints and unshaped VCs scheduled 

using the residual bandwidth after processing shaped VCs. The TM4.1_Scheduler function looks 

for work either from the message queue originating from the TM4.1_Receive function or a 

message queue originating from TM4.1_Shaper function. The schedule (comprising the VP/VC to 

be processed) for the shaped and unshaped VC is stored in a calendar queue. 

Application Note 21


3.5 Transmit Processor Traffic Shaper 

The TM4.1_Shaper function reads a single entry in the calendar queue. Each entry has room to 

contain a must-send VC index (associated with a VC configured as CBR @ PCR or VBR-rt @ 

SCR), a could-send VC index (associated with a VC configured as VBR-rt @ PCR or VBR-nrt 

@SCR) and an unshaped VC index (associated with a VC configured as VBR-nrt @ PCR or 

UBR). The VC indices that will be processed at any given time are prioritized in the order as they 

appear - must-send/could-send/unshaped. If multiple VC indices are present in an entry, the VC 

index with the highest priority gets processed. All other VC indices are re-scheduled without 

transmitting a cell on such VCs. After transmitting a cell, the next cell in that VC’s queue will be 

requested to be scheduled. If a VP/VC index is not found in an entry, the shaper will wait for the 

duration (inter-cell gap + time it takes to process a cell for a given bandwidth). 

3.6 Transmit Processor Traffic Transmit 

The ATM transmit function is passed a VC index and port number. If the VC index indicates to do 

a port skip (no data for the port is available to be transmitted) then a port skip is done and the 

transmit buffer element is updated for the next cell. If flow control is asserted for the port, then a 

port skip is done and the transmit buffer element is updated for the next cell. A packet is de-queued 

from the VC queue. The packet descriptor is then read. The fabric and cell header is generated and 

put into the transmit buffer. The CRC is run on the packet data for this cell and put into the transmit 

buffer. If this is the last cell, then the packet trailer is generated and also put into the transmit buffer. 

The packet is then transmitted and the transmit buffer element is updated for the next cell. 

Next, a check is made with the number of cells en-queued for the VC and the lower queue 

threshold for that VC. If they are equal or the cells en-queued is less than the said threshold, a flow 

control message is sent onto the ready bus indicating to de-assert flow control. The number of cells 

en-queued is then decremented. If this is the last cell of a packet, the packet buffer is put back onto 

the free list of packet buffers. 

4.0 Data and Tables 

4.1 Receive Processor 

4.1.1 Input Data 

This section describes data input to and output from the Receive Processor in the DSLAM 

Example Design. 

Two types of packets may be input to the Receive Processor: 

• Data Packets 

• Flow Control Packets 

Data packets consist of RFC1483-compliant AAL5 PDUs which have been segmented into ATM 

cells and prepended with a custom header. 

22 Application Note


Flow control packets consist of a single unsegmented data packet (having a length of two octets) 

prepended with the same custom header that was prepended to the ATM cells comprising the data 

packets. 

This custom header contains three pieces of information: 

• Whether the packet is data or flow control 

• The type of physical port from which the packet was received (e.g. ATM, Frame Relay, 

Ethernet, etc.). 

• The port number of the physical port from which the packet was received (0-2047). 

Application Note 23


Figure 10 shows how Routed IP over ATM packets are encapsulated with LLC/SNAP and AAL5 

to be carried by ATM cells. These ATM cells are then prepended with the custom DSLAM header 

by the DSL Aggregator. The ATM cells with the prepended DSLAM headers are then input to the 

Receive Processor. 

Figure 10. Receive Processor Input - Routed IP over ATM with DSLAM Header 

Ethernet 

Data 

Ethernet Header 

IP Header 

TCP Header 

Payload 

Ethernet Trailer 

IP 

Data 

IP Header 

TCP Header 

Payload 

LLC/SNAP 

Encapsulation 

LLC OUI PID 

3 bytes 3 bytes 2 bytes IP Header TCP Header 

Payload 

AAL5 

CS 

CS-SDU Info Field 

Padding 

0-47 bytes 

UU 

1 byte 

CPI 

1 byte 

Length 

2 bytes 

CRC 

4 bytes 

SAR 

Sub-Layer 

ATM Cell 

Header 

Payload 

48 bytes 

ATM Cell 

Header 

Payload 

48 bytes 

ATM Cell 

Header 

Payload 

48 bytes 


(input to 

Processor A) 

DSLAM Header 

4 bytes 

ATM Cell 

53 bytes 


4 bytes 

ATM Cell 

53 bytes 

Packet Type 

1 bit 

1=data 

Unused 

18 bits 

Physical Port Number 

11 bits 

(0-2047) 

Physical Port Type 

2 bits 

1=ATM 

A9553-01 

24 Application Note


Figure 11 shows how bridged Ethernet packets are encapsulated with LLC/SNAP and AAL5 to be 

carried by ATM cells. These ATM cells are then prepended with the custom DSLAM header by the 

DSL Aggregator. The ATM cells with the prepended DSLAM headers are then input to the Receive 

Processor. 

Figure 11. Receive Processor Input - Bridged Ethernet over ATM with DSLAM Headers 

Ethernet 

Data 

Ethernet Header 

IP Header 

TCP Header 

Payload 

Ethernet Trailer 

LLC/SNAP 

Encapsulation 

LLC OUI PID Partial Ethernet 

3 bytes 3 bytes 2 bytes 

Header 

IP Header 

TCP 

Header 

Payload 

Ethernet 

Trailer 

AAL5 

CS 


Padding 

0-47 bytes 

UU 

1 byte 

CPI 

1 byte 

Length 

2 bytes 

CRC 

4 bytes 

SAR 

Sub-Layer 

ATM Cell 

Header 

Payload 

48 bytes 

ATM Cell 

Header 

Payload 

48 bytes 

ATM Cell 

Header 

Payload 

48 bytes 


(input to 

Processor A) 


4 bytes 

ATM Cell 

53 bytes 


4 bytes 

ATM Cell 

53 bytes 

Packet Type 

1 bit 

1=data 

Unused 

18 bits 


11 bits 

(0-2047) 


2 bits 

1=ATM 

A9554-01 

Application Note 25


Figure 12 shows how flow control packets are formatted. These packets are then prepended with 

the custom DSLAM header by the DSL Aggregator. The flow control packets with the prepended 

DSLAM headers are the input to the Receive Processor. 

Figure 12. Receive Processor Input - Flow Control Packet with DSLAM Header 

Flow Control 

Flow Control Valid 

1 bit 

Flow Control Message 

2 bits 

Flow ID 

13 bits 

Padding 

46 bytes 


(input to 

Processor A) 


4 bytes 

Flow Control 

48 bytes 

Packet Type 

1 bit 

0=flow control 

Unused 

18 bits 


11 bits 

(0-2047) 


2 bits 

1=ATM 

Note: Flow Control Format 

Flow Control Valid: 0=flow control invalid, 1-flow control valid 

Flow Control Message: 1=go, 1=no go 

Flow ID: 0-8191 

A9555-01 

4.1.2 Output Data 

Data packets and flow control packets are output from the Receive Processor. This output is 

formatted so that the packets may be received by an IXB3208 chip and forwarded on to the 

Transmit Processor. Data and flow control packets are prepended with an “inter-IXP” header 

containing packet classification data for use by the Transmit Processor. Then the packets, with their 

prepended inter-IXP header are segmented per IXB3208 requirements. A special header is 

prepended to each of these segments for consumption by the IXB3208. 

26 Application Note


Figure 13 shows how PDUs and flow control packets output from the Receive Processor to the 

IXB3208 are formatted. These PDUs and flow control packets are prepended with an inter-IXP 

header (containing classification information for traffic management), segmented, and then prepended 

with IXB3208 headers. (IXB3208 headers follow a standard format as specified in the 

IXB3208 documentation.) The input to the Transmit Processor is the same data with the IXB3208 

headers stripped off by the IXB3208. 

Figure 13. Receive Processor Output to IXB3208 

PDU or 

Flow Control 

Reassembled/modified PDU 

or Flow Control 

multiple of 48 bytes 

Classification Inter-IXP Header Reassembled/modified PDU 

or Flow Control 

SAR Sub-Layer 

(output from 

Processor A) 

Intel ® 

IXB3208 

Header 

Payload 

64 bytes 

Intel 

IXB3208 

Header 

Payload 

64 bytes 

Intel 

IXB3208 

Header 

Payload 

64 bytes 

A9556-01 

Figure 14 shows the format of the Inter-IXP header, which is used to communicate packet 

classification data from the Receive Processor to the Transmit Processor. 

Figure 14. Inter-IXP Header Format 

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Offset 

Last Byte 

C A M Type CLP Priority Time Last Quadword in Packet 

in Packet 

0 

Source VC or Vport Destination VC or Multicast Group 1 

Legend 

C 

A 

M 

CLP 

Type 

Priority 

Time 

Last Quadword in 

Packet 

Last Byte in 

Packet 

Source VC or 

Vport 

Destination VC or 

Multicast Group 

Control Indicator 

0 = command packet 

1 = data packet 

ATM Indicator 

0 = unicast packet is not ATM 

1 = unicast packet is ATM 

Multicast Indicator 

0 = unicast packet 

1 = multicast packet 

Cell Loss Priority Indicator 

Connection Type 

1 = 

UBR 

2 = 

VBR 

4 = 

CBR 

The UBR Priority 

Time IXP1200 A spent on the packet in 1 microsec increments. 

The quadword offset from the start of the packet to the last quadword of data for the 

packet 

The last byte in packet is the number of valid bytes in the last quadword 1. 

These appear to be unique numbers per IP address. 

Application Note 27


4.2 Transmit Processor 

4.2.1 Input Data 

This section describes data input to and output from the Transmit Processor in the DSLAM 

Example Design. 

Data packets and flow control packets are input to the Transmit Processor from the Receive 

Processor through the IXB3208 chip. The only difference between the output of the Receive 

Processor and the input to the Transmit Processor is that the IXB3208 headers, which were 

prepended to each of the packet segments, have been removed by the IXB3208. 

Figure 15 shows how PDUs and flow control packets output from the Receive Processor to the 

IXB3208 are stripped of the IXB3208 headers and then input to the Transmit Processor. 

Figure 15. Transmit Processor Input from IXB3208 

Intel ® IXB3208 

Input 

(Processor A output) 

Intel 

IXB3208 

Header 

Payload 

64 bytes 

Intel 

IXB3208 

Header 

Payload 

64 bytes 

Intel 

IXB3208 

Header 

Payload 

64 bytes 

Intel IXB3208 

Output 

(Processor B input) 

Payload 

64 bytes 

Payload 

64 bytes 

Payload 

64 bytes 

28 Application Note


4.2.2 Output Data 

Data packets output from the Transmit Processor consist of RFC1483-compliant AAL5 PDUs 

which have been segmented into ATM cells and prepended with a custom header. 

Figure 16 shows how PDUs are completed, segmented, and output from the Transmit Processor to 

the DSL Aggregator with the prepended custom DSLAM header, just as it was input to the Receive 

Processor. 

Figure 16. Transmit Processor Output 

Processor B 

Input 

Payload 

64 bytes 

Payload 

64 bytes 

Payload 

64 bytes 

Reassembly 

Inter-IXP 

Header 

AAL5 PDU 

AAL5 

CS 


Padding 

0-47 bytes 

UU 

1 byte 

CPI 

1 byte 

Length 

2 bytes 

CRC 

4 bytes 

SAR 

Sub-Layer 

ATM Cell 

Header 

Payload 

48 bytes 

ATM Cell 

Header 

Payload 

48 bytes 

ATM Cell 

Header 

Payload 

48 bytes 


(output to 

Processor B) 


4 bytes 

ATM Cell 

53 bytes 


4 bytes 

ATM Cell 

53 bytes 

Packet Type 

1 bit 

Unused 

18 bits 


11 bits 


2 bits 

A9558-01 

4.3 Connection, Routing, and Hash Tables 

The Receive Processor contains two primary tables: 

• Connection Table 

• Routing Table 

The connection table is accessed by using a pre-computed hash table and algorithm. The ATM VP 

(virtual path), VC (virtual channel), and physical port numbers contained in the input custom 

header are used to create a hash key that is then used to look up the connection entry in the table. 

Each entry in the connection table contains the following: 

• Status of the ATM virtual circuit (VP/VC) 

Application Note 29


• Network model (IP Longest Prefix Match (LPM) or IP 5-Tuple 

• Buffer index which indicates where to store incoming packet segments 

The routing table is used to determine the IP destination of incoming packets and to what format 

they should be converted. This table is accessed by one of two methods as determined from the 

network model in the connection table: 

• IP Longest Prefix Match (LPM) 

• IP 5-Tuple 

Each entry in the routing table contains the following: 

• Destination IP Address 

• Netmask 

• Gateway 

• Physical Outport Port Number 

• VP 

• VC 

• LLC/SNAP Header 

Table 1. L3 Routing Table - IP Route Example 

4.3.1 Rate Manager 

The Rate Manager creates both the VC and Port table. It allows easy customization of the entries 

and is called from the initialization script TM41.ind. 

4.3.1.1 Port Table Entry 

////////////////////////////////////////////////////////////////////////////// 

// Port table entry 

struct Unshaped_VC_{ 

UINT unshaped_unused_0: 8;// For alignment 

UINT WRR_count: 8; // WRR weight associated with unshaped 0-15 VC (cells) 

UINT vc_index: 16;//Base address of queue associated with an unshaped 0-15 

VC 

}; 

typedef struct Unshaped_VC_ Unshaped_VC; 

// 32 lw per entry * 256 ports * 4 = 32Kbytes 

struct Port_Entry_{ 

// LongWord - 0 

UINT entry_valid: 1;// Message queue base address 

UINT port_unused_0: 9;// For alignment 

UINT current_unshaped_queue: 5;// Queue # being processed (0-15) 

UINT q_with_pkts_vector: 17;// Indicator for 16 VC queues and 1 

First_Chance_Q 


30 Application Note


UINT inter_cell_gap: 16; // Shaped wheel slots, indicates port bandwidth 

UINT last_cell_sent: 16; // Shaped wheel slot 


UINT current_WRR_count: 8;// Decrementing WRR count 

UINT WRR_count: 8;// WRR weight assigned to this VC 

UINT current_unshaped_VC_index: 16; // This is the unshaped VC index 

currently 

// being processed 

// LongWord - 3:18 

Unshaped_VC unshaped_VC[16];// 16 unshaped queues and its associated 

weights 

// LongWord - 19;//Intercellgap and Lastcellsent 

Unshaped_VC unshaped_VC[16];// 16 unshaped queues and its associated 

weights 

// LongWord - 20:31 

UINT port_unused_1[13];// For alignment 

}; 

4.3.1.2 VC Table Entry 

////////////////////////////////////////////////////////////////////////////// 

// VC table entry 

// 8 lw per entry * 4096 VCs * 4 = 131Kbytes 

struct VC_Entry_ { 


UINT CRC_Residue: 32;// CRC-32 residue. 


UINT vc_unused_0: 16;// For alignment 

UINT queue_threshold_lo: 8; // Cells 

UINT num_cells_enqueued: 8;// Cells 


UINT entry_valid: 1;// Set to 0 if VC is not configured 

UINT vc_unused_1: 7;// For alignment 

UINT unshaped_q_position: 4;// Offset in port table’ "unshaped_VC" this VC 

is located 

UINT wheel_num: 2;// Totally 4 wheel-pairs. 

UINT type: 2; // Shaped CBR, shaped VBR-rt, shaped VBR-nrt, unshaped 

classes 

UINT port_num: 8;// Physical port # 

UINT queue_threshold_hi: 8; // Cells 


UINT last_SCR_cell_sent: 16;// Slot location in wheel 

UINT current_MBS: 16;// Unused bits padding for alignment 


UINT last_PCR_cell_sent: 16;// Slot location in wheel 

UINT PCR: 16; // Shaped Wheel slots 


UINT MBS: 16; // Cells 

UINT SCR: 16; // Shaped Wheel slots 


UINT atm_header;// AAL5 header 


UINT vc_unused_2;// For alignment (being used for AAL5 Header) 

Application Note 31


}; 

5.0 Project Configuration / Modifying the Example 

Design 

This example design can be assembled with a variety of options, all of which are configurable in 

the header files: project_config.h and system_config.h. 

6.0 Testing Environment 

The testing environment is the same as the execution environment - for details refer to Section 1.3 

of this document. 

7.0 Simulation Support (Scripts, etc.) 

The three Developer WorkBench projects in this design can be run using the simulator within the 

DWB. Test streams, foreign model DLLs, and the simulator scripts that support them, can be used 

to exercise the projects by providing various network traffic inputs to the WorkBench applications. 

7.1 Simulation for the Receive Processor Project 

7.1.1 Initialization Scripts 

The file dslam_proc_a.ind is the primary initialization script for the Receive Processor project. It 

invokes all other simulator scripts, including the dslam_perf_proc_a.ind script and the test case 

scripts described below. The primary functions performed by this script are: 

• Memory Map Initialization 

• Queue Descriptor Table Initialization 

• Scratch Memory Initialization 

• SRAM Task Message Area Initialization 

• Scratch Task Message Area Initialization 

• Fast Port Index Initialization in the Queue Descriptor Table 

• Route Table Manager Initialization 

• Hash Table Manager Initialization 

• Route Additions to the Route Table 

• Invocation of a Selected Test Case Script 

• Start of Packet Reception 

32 Application Note


7.1.2 Test Case Scripts 

Table 2. 

The first nine of ten test cases for the Receive Processor project can be executed using either 

NetworkTraffic.dll or NetSim.dll. The tenth test case (which simulates pass-through of flow 

control packets) must be executed using NetworkTraffic.dll. (At the time of this writing, 

NetSim.dll did not support simulation of flow control packets.) To switch between the use of 

NetworkTraffic.dll and NetSim.dll, the .dll file must be specified in the WorkBench under 

Simulation/IX Bus Device Simulator/Port I/O. The following table shows the test case descriptions 

and the associated script files which must be specified through the initialization script file, 

dslam_proc_a.ind. 

Test Case Descriptions and their Files 

Test 

Case Description 

NetworkTraffic.dll 

(all file names start with: 

dslam_proc_a_ ) 

NetSim.dll 



NetSim TCS File 



001 

Vary 

Physical 

Port 

test_case_001.ind test_case_001_netsim.ind test_case_001.tcs 

002 Vary VP/VC test_case_002.ind test_case_002_netsim.ind test_case_002.tcs 

003 Vary IP test_case_003.ind test_case_003_netsim.ind test_case_003.tcs 

004 

005 

006 

007 

008 

Minimum 

Packet 

Maximum 

Packet 

Medium 

Packet 

IP LPM 

Lookup 

IP 5-Tuple 

Lookup 





test_case_008.ind unsupported unsupported 

009 

MPoA 

Encapsulation 


010 Flow Control test_case_010.ind unsupported unsupported 

Each of the above scripts performs the following functions: 

• Initialization of Either NetworkTraffic.dll or NetSim.dll 

• Addition of Entries to the Connection Table, Including VPI, VCI, and Network Model 

• Generation of ATM Frames for Simulated Input (for use with NetworkTraffic.dll) 

• Generation of ATM Frames for Simulated Input from a NetSim Traffic Configuration 

Specification (.tcs) file (for use with NetSim.dll) 

• Setup of 5-Tuple Rules for IP Route Lookup Using the 5-Tuple Lookup Algorithm 

Application Note 33


7.2 Simulation for the Transmit Processor Project 

7.2.1 Initialization Scripts 

The file, dslam_proc_b.ind, is the primary initialization script for the Transmit Processor Project. 

It invokes all other simulator scripts, including the tm41.ind script and the test case scripts 

described below. The primary functions performed by this script are: 

• Memory Map Initialization 

• Scratch Memory Initialization 

• VC Table Initialization via Rate Manager .dll 

• Port Table Initialization via Rate Manager .dll 

• VPort Ready Vector Initialization 

• VC Queue Heads Initialization 

• Traffic Params Initialization 

• Flow Control Vector Initialization 

• Invocation of a Selected Test Case Script 

• Start of Packet Reception 

• Packet buffer address mailboxes initialization 

• Descriptor mailboxes initialization 

• Rate manager initialization (including population of the VC table) 


Test input for the Transmit Processor project is assigned through the NetworkTraffic.dll. The 

following table shows the test case descriptions and the associated script files that must be 

specified through the initialization script file, dslam_proc_b.ind.: 

34 Application Note


Table 3. 

Test Case Descriptions and their Network Traffic dlls 

Test Case Description NetworkTraffic.dll 

011 

012 

013 

014 

015 

016 

017 

018 

019 

Unassigned Bit Rate 

(single 64-byte cell input) 

Variable Bit Rate (single 

64-byte cell input) 

Constant Bit Rate (single 


All bit rates (single 64-byte 

cell input) 

Unassigned Bit Rate 

(multiple 64-byte cell 

input) 

Variable Bit Rate (multiple 


Constant Bit Rate (multiple 


All bit rates (multiple 64- 

byte cell input) 

Flow-control (single 64- 

byte cell input) 

dslam_proc_b_test_case_011.ind 






dslam_proc_b_est_case_017.ind 



Each of the above scripts performs the following functions: 

• Initialization of the NetworkTraffic.dll 

• Generation of pre-classified ATM frames segmented into 64-byte segments for simulated input 

(for use with NetworkTraffic.dll) 

Currently, test input for the Transmit Processor project is assigned through streams built into the 

Developer WorkBench. These streams may be assigned through Simulation/IX Bus Device 

Simulator/Port I/O. The following table shows the test case descriptions and the associated stream 

files: 

Table 4. 

Test Case Descriptions and their Stream Files 

Test Case Description WorkBench Stream File 

011 Unassigned Bit Rate dslam_proc_b_test_case_0011.strm 

012 Variable Bit Rate dslam_proc_b_test_case_0012.strm 

013 Constant Bit Rate dslam_proc_b_test_case_0013.strm 

014 All Bit Rates dslam_proc_b_test_case_0014.strm 

Application Note 35


7.3 Simulation for the Receive/Transmit Processor Project 

7.3.1 Initialization Script 

The file, dslam_proc_2ixp.ind, is the primary initialization script for the Receive/Transmit 

Processor Project. It invokes all other simulator scripts, including the dslam_perf_proc_a.ind 

script and the test case scripts described below. The primary functions performed by this script are 

a combination of the dslam_proc_a.ind and dslam_proc_b.ind scripts: 

• Memory map initialization 

• Queue descriptor table initialization 

• Scratch memory initialization 

• SRAM task message area initialization 

• Scratch task message area initialization 

• Fast port index initialization in the queue descriptor table 

• Route table manager initialization 

• Hash table manager initialization 

• Rate manager initialization 

• Route additions to the route table 

• Invocation of a selected test case script 

• Start of packet reception 


Four of ten test cases for the 2-processor project can be executed using either the 

NetworkTraffic.dll or the NetSim.dll. The remainder must be executed using the 

NetworkTraffic.dll. (At the time of this writing, the NetSim.dll did not support simulation of flow 

control packets or packets for five-tuple lookup.) To switch between the use of the 

NetworkTraffic.dll and the NetSim.dll, the .dll file must be specified in the workbench under 

Simulation/IX Bus Device Simulator/Port I/O. 

The following table shows the test case descriptions and the associated script files that must be 

specified through the initialization script file, dslam_proc_2ixp.ind. 

36 Application Note


Table 5. 

Test Case Descriptions and their Files 

Test 

Case Description 

NetworkTraffic.dll 


dslam_proc_2ixp_) 

NetSim.dll 



NetSim TCS File 



021 

022 

023 

024 

025 

026 

027 

028 

029 

IP LPM with 

UBR 

IP LPM with 

VBR 

IP LPM with 

CBR 

IP 5TUPLE 

with UBR 

IP 5TUPLE 

with VBR 

IP 5TUPLE 

with CBR 

IP LPM with 

CBR/VBR/ 

UBR 

IP 5TUPLE 

with CBR/ 

VBR/UBR 

IP LPM and 

IP 5TUPLE 

with CBR/ 

VBR/UBR 








test_case_028.ind unsupported unsupported 


030 Flow Control test_case_030.ind unsupported unsupported 

8.0 Performance 

The overall performance of the system is currently limited by the traffic shaping/scheduling and 

transmit portion of the application, and has been measured at speeds just over 400 Mbs. 

9.0 Limitations 

The current implementation of the example design only allows for traffic to pass from the DSL 

aggregator to the WAN, and not vice versa. The design could be relatively easily extended to cover 

traffic in the other direction, but the input from the WAN would need to deliver a custom header 

similar to the one provided by the aggregator, with information on physical ports to send to. 

Similarly, the design only implements the AAL5 segmented ATM transport protocol for the WAN. 

The code has hooks built in for handling both Ethernet and frame relay, which can be filled in to 

that end. This version also doesn’t implement the StrongARM side of packet exception handling, 

nor does it implement any PCI functionality. The example design also uses a custom header for 

physical port information, which, as of the initial release of this document, is not producible with 

our current hardware. Therefore, the design has only had limited software testing, and has, as of 

Application Note 37


this time, not been proven on hardware. The custom header is also just that...custom. This header is 

fully dependent upon the customer’s implementation, and associated code would have to be 

modified to comply with that design. 

10.0 Extending the Example Design 

This implementation allows traffic to pass from the DSL aggregator to the the WAN. The design 

could easily be extended to cover traffic in the reverse direction. In order to do so, data from the 

WAN requires a custom header similar to the one provided by the aggregator indicating the 

physical port to which the data should be sent. 

This design implements AAL5 segmented ATM transport protocol on the WAN interface. It could 

be extended to Ethernet and Frame Relay through the built-in hooks. PCI support has not been 

implemented. 

This design uses a custom header for an assumed physical port information and can be easily 

modified to reflect actual hardware configurations. 

StrongARM processing of exception packets has not been implemented. 

The following “hooks” or support exist in the design to make it easier to add more functionality: 

• Ethernet 

• Frame Relay 

• 2nd Fast Port Use 

• Single Chip 

38 Application Note


11.0 Acronyms & Definitions 

Term 

AAL 

AAL5 

ABR 

API 

ARP (or ATM ARP) 

ATM 

CBR 

CRC 

CS (or AAL5-CS) 


DWB 

IP 

IXB3208 

MAC 

PDU 

Transactor 

UBR 

VBR 

VC 

VP 

WAN 

ATM Adaptation Layer 

Definition 

ATM Adaption Layer 5 (data) 

Available Bit Rate 

Application Programming Interface 

Address Resolution Protocol 

Asynchronous Transfer Mode 

Constant Bit Rate 

Cyclic Redundancy Check 

Convergence Sub-Layer 

Digital Subscriber Line Access Multiplexer 

Developer’s Workbench - Integrated Development 

environment for the IXP1200 Network Processor 

Internet Protocol 

IX Bus device used in multiprocessor IXP1200 systems 

where the intention is to scale for additional port count. 

Supports speeds up to 83 MHz. 

Media Access Controller 

Protocol Data Unit 

IXP1200 Software Simulator 

Unspecified Bit Rate 

Variable Bit Rate 

Virtual Channel 

Virtual Path 

Wide Area Network 

Application Note 39


12.0 Reference Documents 

Title 

Description 

RFC1483.htm 

README.TXT 

DSLAM Router/Traffic Shaper 

SW Design Specification 

A Network Processor-Based 

Next Generation DSLAM 

Multiprotocol Encapsulation over ATM Adaptation Layer 5 Request 

for Comments document - bundled with source code. 

Release notes bundled with source code. 

Note that there are two README.TXT files. One is in the 

atm_ether project source directory, and is a “Quick Start and 

Source Code Guide.” The second README.TXT file can be found 

in the vxworks sub-directory, and describes how to run the project 

on hardware. 

White Paper 

White Paper 

40 Application Note

Digital Subscriber Line Access Multiplexer (DSLAM) Example Design

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?