Frame Relay to ATM to 10/100 Ethernet Switch Router Application Guide

C-WARE SOFTWARE TOOLSET, VERSION 2.4

CSTAFRAE-UG/D Rev 00 Copyright © 2004 Motorola, Inc. All rights reserved. No part of this documentation may be reproduced in any form or by any means or used to make any derivative work (such as translation, transformation, or adaptation) without written permission from Motorola. Motorola reserves the right to revise this documentation and to make changes in content from time to time without obligation on the part of Motorola to provide notification of such revision or change. Motorola provides this documentation without warranty, term, or condition of any kind, either implied or expressed, including, but not limited to, the implied warranties, terms or conditions of merchantability, satisfactory quality, and fitness for a particular purpose. Motorola may make improvements or changes in the product(s) and/or the program(s) described in this documentation at any time. C-3e, C-5, C-5e, C-Port, and C-Ware are all trademarks of C-Port, a Motorola Company. Motorola andthe stylized Motorola logo are registered in the US Patent & Trademark Office. All otherproduct or service names are the property of their respective owners. CSTAFRAE-UG/D Rev 00 CONTENTS

About This Guide Guide Overview ...... 7 Using PDF Documents ...... 8 Guide Conventions ...... 9 Revision History ...... 10 References to CST Pathnames ...... 11 Related Product Documentation ...... 12

CHAPTER 1 Frame Relay to ATM to 10/100 Ethernet Switch Router Application Guide Overview ...... 13 Prerequisite Reading ...... 13 System Configuration ...... 13 Application Feature Overview ...... 14 Feature Overview and Standards Support ...... 14 AAL-5 Segmentation and Reassembly ...... 15 Layer 3 IP Routing ...... 15 ICMP Support ...... 15 IEEE 802.3x PAUSE ...... 15 Application Components Used ...... 16 Application Control and Data Flow ...... 16 Resource Utilization ...... 16 XPRC ...... 16 CP ...... 18 CPRCs 0 to 1, Ethernet ...... 18 CPRC ...... 18 CPRC/SDP Interface ...... 19 SDP ...... 20 RxSDP ...... 20 RxBit Processing ...... 21 RxByte Processor ...... 21 TxSDP ...... 22

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 4 CONTENTS

TxByte Processor ...... 22 TxBit Processing ...... 23 CPRCs 7 and 8 (Frame Relay) ...... 23 CPRC ...... 23 On the Rx thread ...... 23 On the Tx thread ...... 24 SDP ...... 25 RxByte processor ...... 25 RxBit Processor ...... 25 TxByte processor ...... 26 TxBit processor ...... 26 CPRCs 4 to 7, (ATM) ...... 26 CPRC ...... 26 SDP ...... 28 RxBit ...... 28 RxSync ...... 28 RxByte ...... 28 TxByte ...... 29 TxBit ...... 29 CPRCs 12 to 15 (SAR) ...... 29 Segmentation processing ...... 30 Reassembly processing ...... 30 SDP ...... 31 TxByte ...... 31 RxByte ...... 32 TxBit and RxBit ...... 33 TLU ...... 33 ATM VC Table ...... 33 AAL5 VC table structure is as below- ...... 33 IP Forwarding Table ...... 33 Following is the IP route data structure that is used in IP lookup (16 bytes) ...... 34 Bridge Forwarding Table ...... 34 Bridge address table structure is as below ...... 34 Table building in C-5 and C-5e ...... 34 BMU ...... 34

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION CONTENTS 5

QMU ...... 35 IP Descritor Definition ...... 35 appData1 & appData2 in Ethernet interface ...... 36 appData1 in Frame Relay Interface indicates DLCI ...... 36 appData1 in ATM indicates VcIndex ...... 36 Control Descriptor used for handling signalling and Layer management DLCIs in Frame Relay ...... 36 Control desciptor used to send control message from CPRC to XP in Ethernet ...... 36 ICMP message descriptor used in MAC ...... 36 RAS AAL5 PDU descriptor used in ATM ...... 37 FP ...... 37 Host Processor Interaction ...... 37 Offline Table Building ...... 37 Design Issues ...... 37 Extract Space Register Definitions ...... 37 Extract Space Layout ...... 38 Reassembly Extract space layout- ...... 39 Frame Relay Extract space layout- ...... 39 IP Header layout in Extract space ...... 39 Merge Space Register Definitions ...... 39 Merge Space Layout ...... 40 For the Ethernet interface the Merge Space looks like- ...... 40 For ATM interface, the merge space layout is ...... 40 For segmentation unit, the merge space definition is ...... 41 ...... 41 For re-assembly unit, the merge space definition is ...... 41 Performance ...... 41 Frame Relay interface operates on T3/E3 speed- ...... 41 Calculations for T3 ...... 41 Calculations for E3 ...... 42 ATM OC-3c Interface (operating at 155.52Mbps) ...... 43 Calculating the SONET OC-3c payload envelope size ...... 43 Ethernet 10/100 Mbps interface ...... 44 Calculations for 10 Mbps ...... 44 Number of frames on fully loaded 10 Mbps line in one second ...... 44 Calculations for 100 Mbps ...... 44 Number of frames on fully loaded 100 Mbps line in one second ...... 44

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 6 CONTENTS

Supplied Application Files ...... 45 Interfaces ...... 45 XPRC ...... 46 CPRC ...... 47 SDP ...... 49 Binaries ...... 50

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D Rev 00 ABOUT THIS GUIDE

Guide Overview This document describes the design and features of the C-Ware Frame Relay to ATM to 10/100 Ethernet Switch Router application (application identifier switchRouter) . This guide is intended for users of the C-Ware Software Toolset (CST) who want to build any application provided in the CST or who want to develop new C-Ware-based applications targeted to a C-Port network processor device. This guide contains one chapter that covers the following major topics: • Overview • System Configuration • Application Feature Overview • Application Control and Data Flow • Resource Utilization • Design Issues • Supplied Application Files

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 8 ABOUT THIS GUIDE

Using PDF Documents Electronic documents are provided as PDF files. Open and view them using the Adobe® Acrobat® Reader application, version 3.0 or later. If necessary, download the Acrobat Reader from the Adobe Systems, Inc. web site: http://www.adobe.com/prodindex/acrobat/readstep.html PDF files offer several ways for moving among the document’s pages, as follows: • To move quickly from section to section within the document, use the Acrobat bookmarks that appear on the left side of the Acrobat Reader window. The bookmarks provide an expandable ‘outline’ view of the document’s contents. To display the document’s Acrobat bookmarks, press the ‘Display both bookmarks and page’ button on the Acrobat Reader tool bar. • To move to the referenced page of an entry in the document’s Contents or Index, click on the entry itself, each of which is “hot linked.” • To follow a cross-reference to a heading, figure, or table, click the blue text. • To move to the beginning or end of the document, to move page by page within the document, or to navigate among the pages you displayed by clicking on hyperlinks, use the Acrobat Reader navigation buttons shown in this figure:

Beginning of document End of document

Previous or next hyperlink

Previous page Next page

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Guide Conventions 9

Table 1 summarizes how to navigate within an electronic document.

Table 1 Navigating Within a PDF Document

TO NAVIGATE THIS WAY CLICK THIS Move from section to section within the A bookmark on the left side of the Acrobat Reader document. window Move to an entry in the document’s Contents The entry itself or Index. Follow a cross-reference (highlighted in blue The cross-reference text text). Move page by page. The appropriate Acrobat Reader navigation buttons Move to the beginning or end of the The appropriate Acrobat Reader navigation document. buttons Move backward or forward among a series of The appropriate Acrobat Reader navigation hyperlinks you have selected. buttons

Guide Conventions The following visual elements are used throughout this guide, where applicable: This icon and text designates information of special note.

Warning: This icon and text indicate a potentially dangerous procedure. Instructions contained in the warnings must be followed.

Warning: This icon and text indicate a procedure where the reader must take precautions regarding laser light.

This icon and text indicate the possibility of electrostatic discharge (ESD) in a procedure that requires the reader to take the proper ESD precautions.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 10 ABOUT THIS GUIDE

Revision History Table 2 provides details about changes made for each revision of this guide.

Table 2 Build System Conventions Guide Revision History

REVISION DATE CHANGES 00 4/2002 New document.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION References to CST Pathnames 11

References to CST You typically install the C-Ware Software Toolset (CST) on your development workstation Pathnames in a directory path suggested by the installation procedure, such as: • C:\C-Port\Cstx.y\ (on Windows 2000/XP) • /usr/yourlogin/C-Port/Cstx.y/ (on Sun SPARC Solaris and Linux) or: /usr/cport/C-Port/Cstx.y/ or: /opt/C-Port/Cstx.y/ where ‘x’ is a major version number and ‘y’ is a minor (or intermediate) version number. You typically install each CST version under some directory path ...\C-Port\Cstx.y\. However, the user can install the CST in any directory on the development workstation. The user can also install more than one CST version on the same workstation. Therefore, to refer to installed CST directories, we use pathnames that are relative to the ...\C-Port\Cstx.y\ path, which is the “root” of a given CST installation. For example, the apps\gbeSwitch\ directory path refers to the location of the Gigabit Ethernet Switch application that is installed as part of the CST. The full path of this directory on a Windows 2000/XP system might be C:\C-Port\Cst2.1\apps\gbeSwitch\, so this convention is convenience for shortening the pathname. Other top-level directories that are installed as part of the CST include bin\, diags\, Documentation\, services\, and so on. These directories are described in the C-Ware Software Toolset Getting Started Guide document, which is part of the CST documentation set.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 12 ABOUT THIS GUIDE

Related Product Table 3 lists the documentation for the C-Ware library of reference applications. Documentation Table 3 C-Ware Application Library Documentation Set

DOCUMENT NAME PURPOSE DOCUMENT ID AAL-5 Fabric Port SAR to Gigabit Ethernet Describes the key characteristics of the gbeOc12SarFp CSTAA5F2G-UG Switch Application Guide applications. AAL-5 SAR to Gigabit Ethernet Switch Describes the key characteristics of the gbeOc12Sar application. CSTAA52G-UG Application Guide FibreChannel to Gigabit Ethernet IP Gateway Describes the key characteristics of the gbeFc application. CSTAFC2G-UG Application Guide Frame Relay to ATM to 10/100 Ethernet Switch Describes the key characteristics of the switchRouter application. CSTAFRAE-UG Router Application Guide Gigabit Ethernet Switch Application Guide Describes the key characteristics of the gbeSwitch application. CSTAGBE-UG Multi-PHY Switch Application Guide Describes the key characteristics of the mphySwitch application. CSTAMPHYS-UG Packet Over SONET Switch Application Guide Describes the key characteristics of the posOc48Sc application. CSTAPOS-UG Packet Over SONET to Ethernet Switch Describes the key characteristics of the enetOc3Switch CSTAPOS2E-UG Application Guide application. Packet Over SONET to Gigabit Ethernet Switch Describes the key characteristics of the posGbeSwitch CSTAPOS2G-UG Application Guide application. Voice Over IP to Voice Over ATM Media Gateway Describes the key characteristics of the voIpToVoAtmSwitch CSTAVOIP-UG Application Guide application. Fabric Processor Configuration Component Describes the key characteristics of the fabrics application CSTCFPC-UG Guide component. GMII Gigabit Ethernet Autonegotiation Describes the key characteristics of the gmiiAutoNeg application CSTCGEAN-UG Component Guide component. ICMP Support Component Guide Describes the key characteristics of the ip application component. CSTCICMP-UG MPC750 SBC Host Stack Support Component Describes the key characteristics of the stackSupport application CSTCMHSS-UG Guide component. PHY Configuration Component Guide Describes the key characteristics of the phy application CSTCPHYC-UG component. QMU Configuration and RC Support Describes the key characteristics of the queueUtils application CSTCQRCS-UG Component Guide component. SONET Monitoring Component Guide Describes the key characteristics of the sonet application CSTCSMC-UG component.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D Chapter 1 Rev 00 FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

Overview This document is a functional and design specification for the C-Ware switchRouter application in the CST. This application is essentially a interworking of three application interfaces: FrameRelay (T3/E3), Ethernet (10/100 Mbps) and ATM (OC-3c). This document goes into detail about the following topics: • Application Feature Overview (each of the 3 interfaces) • Resource Utilization • Design Issues

Prerequisite Reading Readers of this document are assumed to have read or be familiar with the topics in the following documents in the CST: • C-Ware Software Toolset Getting Started Guide - How to get started with the CST. • Build System Conventions - Description of how the build system works. • C-Ware Microcode Programming Guide - To understand the SDP functionality • Familiarity with ATM/Ethernet/FrameRelay protocols to understand the interfaces

System Configuration This application runs on the following modules as a part of the C-Ware Development System (CDS): • C-5 Switch Module (Only in Simulation) • C-5e Switch Module (Only in simulation)

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 14 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

This application runs with the following Physical Interface on C-5 Simulator: • 2 x 10/100 Ethernet • 4 x ATM OC3c (155.56 Mbps) (TBI) • 2 x FrameRelay (T3/E3)

Application Feature The switchRouter application in the CST is an interworking router application in which IP Overview packets are routed over Frame Relay, Ethernet or ATM interfaces.

Feature Overview and This application supports the following features: Standards Support • 2 x T3/E3 interfaces for Frame relay, 2 x 10/100 Mbps for Ethernet, and 4 x ATM OC-3c channels with SAR (segmentation and reassembly) implemented on a separate cluster (using four CPRCs) • Frame relay Header processing (only DLCI) for forwarding decisions • Variable length Frame-relay packet sizes between (64 to 1600 bytes) • IP encapsulation within FR by using RFC-2427 (Option I) • Bit Sync HDLC support - checking of frame delimiting, alignment, frame abort, FCS (16 bit) • Setting up of the Static Routing Table for ATM/Ethernet/Frame Relay interface • Unicast forwarding based on 10 bit DCLI (0 for signalling, 1-15 & 1008-1022 are reserved, 992-1007 & 1023 for layer management and 16-991 for VCs) • Layer 3 forwarding (IP Routing) IP over Ethernet or Frame relay or ATM • ICMP support for TTL expired, destination unreachable, redirect in all of the FR, Ethernet and ATM interfaces • AAL-5 segmentation and reassembly • SONET monitoring • Multiprotocol encapsulation over AAL-5 layer (RFC-2684) using VC multiplexing so that LLC SNAP header is not needed. RFC -1483 has been obsolated by RFC-2684

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Application Feature Overview 15

AAL-5 Segmentation and Reassembly Layer-3 IP packets traversing from Ethernet or Frame-relay to ATM are AAL-5 encapsulated in the SAR cluster. Similarly, cells traversing from ATM to Ethernet or Frame-relay are reassembled into packets. The proper encapsulation of IP (or any other protocol) over AAL-5 is discussed in RFC1483. If the data is traversing from an ATM to another ATM interface, the incoming cells are reassembled in the SAR cluster; the encapsulated IP packet is examined and again the packet is chopped into cells. These cells are then sent to the outgoing ATM interface.

Layer 3 IP Routing IP routing is the process of forwarding IP frames at layer 3 based on IP destination Address (IP DA). An Advantage of IP routing is that it can be used between dissimilar media types such as Frame Relay, Ethernet, ATM. In the switchRouter application, a Static routing table is built. The lookup of an IP-DA address will result in a VPI/VCI pair and interface number for ATM, DLCI values and interface number for Frame relay, or MAC-DA address and interface number for Ethernet. This information is embedded in headers of the outbound packet and the packet or cell is delivered to designated queue associated with the corresponding interface.

ICMP Support The switchRouter application supports three types of ICMP messages for each of the three interfaces namely, Ethernet, Frame Relay and ATM. • ICMP time exceeded • ICMP No route • ICMP Destination Unreachable The reason that these messages are supported in the switchRouter application is that they are based on events in the datapaths, as opposed to the control path.

IEEE 802.3x PAUSE IEEE 802.3x PAUSE is a standard for Ethernet MAC devices that provides link level flow control. This provides a mechanism for an Ethernet interface to stop the transmission of frames for the predetermined time. This feature is invoked by C-5 NP to its link partner when it is running low on packet buffers. When this situation occurs, it sends a MAC PAUSE frame on the given interface.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 16 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

When one of these frames is received from the link partner, the C-5 NP stops sending the data over that interface for the requested amount of time.

Application Components The CST provides a number of application components that are used across applications. Used This application uses the following application components provided in the CST. • ip See the documentation in the apps/components//doc/ directory for the documentation on the software components that this application uses.

Application Control and Figure 1 on page 17 shows the dataflow diagram and interworking of Ethernet, ATM and Data Flow FrameRelay. Other traffic flows can be shown in similar way.

Resource Utilization To support this application’s features, the C-5 NP’s embedded processors are performing a variety of tasks. The sections below enumerate what functionality is taking place and how the different processors are being used.

XPRC The Executive Processor RISC core (XPRC) is a general-purpose processor that provides the management control and exception processing function. The XP controls the C-5 NP boot up, configuration and initialization of all of the system components. The application’s XP program is partitioned into 3 distinct stages: 2 initialization stage executables and a “main” executable. After loading and running the initialization executables, the main executable is loaded and overlayed on the initialization executable, reducing the IMEM used at runtime. First stage initialization also loads and calls the second stage XP initialization. Second stage initialization executable configures system resources, and initializes the SDPs. The XP main executable performs services initialization, starts the CPRCs related to Frame Relay, Ethernet, ATM and SAR processing and sends them the initialization descriptors as a queue message.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 17

Figure 1 Diagram of Application Control and Data Flow

Queue Storage Table Storage External and Statistics Host (SRAM) (SRAM) CPU SDRAM Fabric

PCI Processor Boundary

FP TLU XP QMU BMU Ring Bus

6 Global Bus

9 5 2 Payload Bus 10 7 12 4 3 11 Cluster

ETH (10/100 Mbps) ATM OC-3c FR T3/E3 SAR(Seg) SAR(Reassem)

CP0CP1 CP2 CP3 CP4 CP5 CP6 CP7 CP8 CP9 CP10 CP11 CP12 CP13 CP14 CP15

8

C-5 NP 13 1 PHY Dest = ATM CP5 Ethernet frame Outgoing ATM Cells

1 Ethernet SDP receives a frame. 2 Ethernet RxByte launches lookup for the IP destination address. 3 RxByte DMAs the payload to SDRAM through BMU. 4 Ethernet CPRC receives the lookup response. 5 Ethernet CPRC builds Q Descriptor and queues it to destination through QMU. 6 Segmentation CP dequeues the descriptor from its queue through QMU. 7 Segmentation TxByte DMA payload from SDRAM. 8 Segmentaion TxSDp recirculates the payload to RxSDP. 9 Seg RxByte DMAs payload to SDRAM through BMU. 10 CPRC forms the descriptor and queues it in QMU. 11 ATM dest CP dequeus the descriptor. 12 SDP DMAs the payload from SDRAM through BMU. 13 ATM TxSDP sends the cells out.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 18 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

Finally, it stays in a loop monitoring any SONET faults or defects and looking at an XP queue for any message. The messages could be Frame Relay packets with header containing signalling or layer management DLCI. CPRC-Rx thread sends these frames to XP. At present, XP just ignores these messages and frees the buffer. Also when the Ethernet frame processing is finished (that is, after both the scopes on RC side have finished their work), the receive port is put into disabled state by shutting off the SDP. Port disable message is sent to XP. The XP processes these messages and frees the corresponding buffer handles as may be needed.

CP The C-5 NP’s 16 channel processors (CPRCs) are the components most closely associated with processing data from the physical interface. Each CP performs several functions in switchRouter application: • Support for 2 x Ethernet (10/100Mbps) interface • Support for 2 x FR (Frame Relay) interface • Support for 4 x OC-3c ATM interface • Support for 1 cluster of recirculation for SAR (Segmentation and Reassembly)

CPRCs 0 to 1, Ethernet There are 2 Ethernet 10/100Mbps interfaces.

CPRC The CPRC program is used for the following functions in the Ethernet interface processing: • Processing the lookup results from the TLU. (Following are the lookups that CPRC processes) – MAC DA lookup – MAC SA lookup – VLAN to FID lookup – IP DA lookup – IP Multicast • Constructing a descriptor for forwarding to the QMU.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 19

• Characterizing the frame and making forwarding decisions based on the TLU lookup results and frame parsing. • Initiating receive program on the RxSDP • Initiating transmit program on TxSDP

CPRC/SDP Interface The CPRC interfaces to the TxByte processor via a set of special purpose registers called Merge Space registers. The Merge Space registers are used to communicate information such as whether outgoing frames should be routed, bridged, or tagged with a VLAN identifier. The CPRC and the RxByte processor share a set of registers to do table lookup processing over the Ring Bus. Lookup requests are referenced using a request tag, that refers to one of four Ring Bus registers assigned for initiating requests. Slots 0 and 1 are accessible to the SDP, while slots 0 through 3 are accessible to the CPRC. Each slot contains a 4Byte control register and two 4Byte data registers. These data registers contain information to be delivered to the TLU such as the type of lookup being requested and the key information to use in determining a match. Depending on the type of lookup being issued and the length of the key, the number of slots needed for any single lookup can be 1, 2, or 4. The following request tags are used by the SDP in the Ethernet application: • MAC DA lookup: Uses slots 0. • MAC SA lookup: Uses slots 0. • VLAN to FID lookup: Uses slot 0. • IP DA lookup: Uses only slot 1. • IP Multicast: Uses slots 1. The following request tags are used by the CPRC in the Ethernet application: • MAC DA lookup: Uses slots 2. • MAC SA lookup: Uses slots 2. Note: Because the same request tag is used for multiple lookups, the application needs to check the AVAIL bit in the Ring Bus transmit control register to make sure the register is

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 20 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

available for use by the program. The CPRC also has access to a set of Ring Bus receive control registers for checking lookup responses referred to as response tags. These response tags map to one of eight response slots available to CPRC, each of which contains a 4Byte control and 8Byte data portion. One response slot is therefore necessary for every eight bytes of data being returned from a lookup. When a lookup is initiated by either the SDP or the CPRC, the slot on which the response should land is indicated in the request. The status of the response is then checked by the CPRC using the appropriate response tag and the data returned is read upon receipt of a successful lookup indication. The following response slots are assigned in the Ethernet application: • MAC DA response: Uses slots 0 and 1 to support the return of 16 bytes of data. • MAC SA response: Uses slots 2 and 3 to support the return of 16 bytes of data. • IP DA response: Uses slots 4 and 5 to support the return of 16 bytes of data. • IP Multicast response: Uses slots 4 and 5 to support the return of 16 bytes of data. • VLAN VID to FID response: Uses only slot 6 to support the return of 8 bytes of data.

SDP

RxSDP The RxSDP performs bit- and byte-level interpretation and parsing of the incoming Ethernet stream. In addition to providing general receive processing, the RxSDP supports the following Ethernet-specific Switching functions: • Frame delineation • Preamble detection • Control character detection • Header parsing • Lookup initiation • Header validation • CRC validation • CPRC forwarding path determination

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 21

RxBit Processing The initial processing of the incoming data stream involves: • Serial to Parallel Conversion: The 8bit data is converted from serial to parallel format for processing by the RxSDP. • Preamble Detection: The RxSDP is programmed to detect the Ethernet preamble and start of frame (SOF) delimiter. After the bit pattern is detected, these bytes are stripped off of the frame before additional RxSDP functional parsing of the Ethernet frame. • Frame Length Validation: The RxSDP validates that incoming frames are in the range of 64 to 1518 bytes (to 1522 bytes if 802.1q).

RxByte Processor The RxByte Processor is a serial processor within the RxSDP. It is responsible for the byte-level processing of Ethernet data from the physical interface. Specific physical layer and MAC functions include: • Header Detection: The RxByte processor detects the start of the layer 2 MAC and layer 3 IP header of incoming Ethernet frames. • Header Validation: The RxByte processor validates the layer 3 IP headers of the incoming Ethernet frame. All of the validation that is required by an IP Router is done by the RxByte processor with the exception of validating the IP DA or IP SA. Validation on the IP DA or IP SA is done by virtue of not installing illegal IP Addresses into the Table Lookup Unit (TLU), which results in failed lookup results from the TLU. • Initiation of MAC DA, MAC SA, IP DA Lookups, IP Multicast, and VLAN to FID: The RxByte processor launches lookups for the IP DA to the TLU for evaluation by the CPRC while the packet is being received. Other MAC lookups are not launched on IP encapsulated packets. • Validation of the Ethernet CRC: The RxByte processors CRC-32 engine calculates an ongoing Ethernet CRC for the received frame and verifies that the CRC on the frame is correct. • Determination of CPRC Forwarding Path: The RxByte processor provides information to the CPRC informing it of what forwarding path (such as unicast, flooded, routed, or IP multicast) to use for the frame. • Error and Status Reporting: The RxByte processor program reports errors and frame status to the CPRC via extract space. This includes any physical layer error, CRC, frame length, header validation errors, and so on.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 22 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

TxSDP The Transmit Serial Data Processor (TxSDP) performs bit- and byte-level transmission of the outgoing Ethernet stream. In addition to providing general transmit processing, the TxSDP specifically supports the following Ethernet Switching functions: • Modification of the IP header • Decrementing of the IP Time-to-Live (TTL) • Recalculation of the IP Header Checksum • Regeneration of the Ethernet CRC • Regeneration of 802.1Q VLAN headers for tagged frames • Ethernet MAC functions.

TxByte Processor The TxByte Processor is a serial processor within the TxSDP. It is responsible for the following functionality in the Ethernet application: • Transmits bytes: The TxByte processor reads bytes from CP DMEM and then loads the bytes into the largeFIFO in order to stage transmission to the TxBit processor. • Frame modification in case of IP routing: TxByte processor modifies the datalink header according to the MAC DA and MAC SA in Merge Space (populated by the CPRC), decrements the TTL, and updates the IP Checksum. In the case of 802.1Q VLAN switching, the TxByte processor adds the 802.1Q header and VLAN tag when appropriate. • CRC generation: The Ethernet CRC is recalculated and appended to the end of the Ethernet frame. • Ethernet padding: If the length of the Ethernet frame to be transmitted is less than 60 bytes (without the CRC), the TxByte processor pads the frame out to 64 bytes to meet minimum Ethernet packet size requirements. • CPRC coordination: For transmit error handling (such as collision detection when operating in half-duplex mode), the RxByte processor coordinates and communicates status information with the CPRC via both Merge Space and Control Space.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 23

TxBit Processing In addition to the processing performed by the TxByte Processor, the TxSDP performs the following Ethernet functions to support bit-level transmit processing of an Ethernet frame: • IFG generation: The TxBit processor generates the correct Inter-Frame Gap (IFG) according to the speed of the physical interface. • Preamble generation: The TxBit processor generates both the Ethernet preamble and start-of-frame delimiter for the Ethernet frame.

CPRCs 7 and 8 (Frame Relay) These CPRCs provide 2 x (T3/E3) Frame relay interfaces.

CPRC CPRC handles the Frame relay packets as follows:

On the Rx thread • Set up the frame relay descriptor in memory • Initializes the Frame relay statistics • Waits in a loop for getting the handle on the datascope which indicates the arrival of a frame header for processing • Gets the buffer handle for the current payload • Checks the DLCI whether it is a layer management, signalling or routing DLCI. • In case of Layer Management and Signalling DLCI, CPRC composes the control descriptor and enqueues the payload to XP queue. • In case of routing DLCI, CPRC checks for the IP encapsulation using VNID_Client field value written by RxSDP. It essentially ensures that the IP packet is encapsulated inside the Frame relay payload. • SDP launches the IP DA lookup from RxByte using 4 byte destination address as key on request slot 0. CPRC receives the table lookup on response slot 4 and supports returns 16 bytes of data (IP descriptor). • CPRC then waits for the IP response to arrive at the appropriate response slot on a ring bus. The IP DA response returns the information on the outbound interface id and

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 24 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

appropriate destination address for that interface (that is, VPI/VCI for ATM, MAC address for Ethernet, and DLCIs for Frame Relay). • The IP DA table lookup may return a valid response for destination addresses that exist in IP table, but otherwise the status could be destination unreachable or redirect message. • In case of a valid IP DA response, the CPRC composes the descriptor using the values returned by the lookup and sends it to the appropriate interface and also enqueues the payload on the target queue. • In the case of a destination unreachable or a redirect, the CPRC composes the ICMP message using the source DLCI values and delivers it back to the sender. • If RxSDP detects an error in the frame, it indicates this to the CPRC through the Extract Space register. The CPRC updates the errors statistics, releases the look up response slots whenever the lookup is already launched by RxSDP (that is, TTL expired, frame overrun, frame underrun), and composes the ICMP messages to indicate sender about the error (that is, in the case of TTL expired). • Congestion control and traffic management is not handled in the frame relay interface yet.

On the Tx thread • CPRC keeps polling the queue for any message descriptor available that needs processing and then waits for the merge space to be available to transmit the header information regarding current frame to TxSDP. • Tx of Frame Relay thread can receive IP descriptor from ATM/Ethernet or Frame Relay interfaces. • It dequeues the descriptor and extracts DLCI values and the interface number to be used for outbound FR frame. • Writes the outbound destination address to merge space (VPI/VCI or MAC or DLCI address). • Writes the encapsulation details (control=0x03 and NLPID=0xCC as per RFC 2427) to merge space. • Sets up the DMA engine to transmit the payload onto the wire. • Gives the scope to the TxSDP to trigger processing of the header and payload.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 25

SDP The Serial Data Processor performs bit- and byte-level interpretation and parsing of the incoming Frame relay packet as well as creation of outgoing Frame relay packets.

RxByte processor The RxByte processor is a serial processor within the RxSDP. It is responsible for byte-level processing of the frame relay packets stream coming from the physical interface. It’s responsibilities include: • Frame Relay header detection • Header validation on DLCI values (presently the SwitchRouter application does not check the traffic-control related fields such as FECN, BECN, DE bits) • Frame relay FCS computation • Validation of IP encapsulation in FR using control & NLPId bytes. (see RFC 2427) • IP Header is validated and the status is written to extrace space • IP header checksum is validated to ensure that header is received correctly. • FR payload (excluding RFC encapsulation 2-bytes) that is, IP header and payload is transferred to SDRAM using DMA. • Launches table lookup on IP-DA address on request slot 0 using 4 byte IP destination address as lookup key. • Detects Short frame (less that 64 bytes), long frame (more than 1600 bytes), and seven 1’s error, writing error status to extract space. • Frame discard on specific errors and writing the error status in extract space.

RxBit Processor • Flag (0x7E) detection and packet extraction. • Frame discard on detection of 7 or more consecutive 1’s; notify this error to CPRC through extract space. search for next Flag. • Bit destuffing (removing 0 that occures after 5 consecutive 1’s) • Checking the packet alignment (packet remain byte boundary aligned after destuffing).

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 26 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

TxByte processor • Creates FR header using DLCI values. Congestion control information is not used, so corresponding fields are set to zero (that is, FECN, BECN, DE bits). • RFC 2427 encapsulation bytes are sent (control = 0x03 and NLPId = 0xCC). • IP header checksum is computed after decrementing the TTL by 1. • Frame header checksum is recomputed and attached at the end of packet. • Frame is sent on wire on given FR interface.

TxBit processor • Flag Generation (0x7E): Flag is sent as frame boundaries for every frame that is sent and also during the idle time when there are no packets to send on the wire. • Ensure that the Flag (0x7E) and the abort bytes (7 or more consecutive 1’s) are not simulated within the FR packet. • Bit stuffing: To insert 0 after every five consecutive 1’s that are read within byte of a packet. five 1’s needs not be byte aligned. This sequence can appear anywhere in the bit streams. • Continuous transmission of flag (0x7E) bytes when there is no data to send.

CPRCs 4 to 7, (ATM) These CPRCs provide 4 x OC-3c ATM interfaces. Each CP handles the ATM cells for its own interface.

CPRC The CPRC program processes received ATM cells as follows: • Using the calls to the C-Ware API’s PDU services routine, the CPRC program sets up the receive control block to receive the cell payload in the DMEM buffer, while the CPRC waits for cell header lookup launched by SDP to complete, it holds the payload in DMEM buffer. • The cell header lookup result contains the buffer handle and the working offset of the current reassembly buffer for the VC indicated in the cell header. Via PDU service call, the CPRC passes the buffer handle and offset to receive control block. DMA engine then transfers the payload to SDRAM from DMEM at the correct offset within the buffer indicated by the buffer handle.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 27

• The entire AAL-5 PDU is reassembled until the last cell of the PDU is received, the entire PDU buffer is then transferred to SAR cluster for verification of length and CRC. • For each cell that is processed, its VC state must be updated in the TLU as follows. – If it is the first cell in the PDU and its lookup result contains a NULL buffer handle, the cell is considered the first one in the new AAL-5 PDU and the new buffer handle must be allocated. – If this is not the last cell in the of a PDU, the offset must be updated in the VC state entry in the TLU. If this is the last cell in the PDU, the buffer handle in the VC state entry must be set to NULL. • The CPRC processes the transmit cells in this way (Segmentation and Reassembly processing is explained in next section): – From Frame relay or Ethernet port to ATM port: The static routing table entries contain the information necessary to forward the IP packets received by the frame relay or Ethernet port to the SAR cluster for segmentation into ATM cells. The routing entry contains the VPI/VCI of the target VC and an output ATM port identifier associated with this VC. The IP forwarding routine places this information in the descriptor that it forwards to the segmentation process. – From ATM to ATM port: The SAR reassembly unit launches the IP table lookup on the IP-DA address after forming the ATM-AAL-5 payload and examining the IP packet. This happens in the RxByte processor. The lookup response is received by reassembly CPRC unit. The packet is enqueued in segmentation CPRC. The IP lookup response also tells, through its descriptor, which ATM interface among the 4 ports that it has to go to. The Segmentation CPRC enqueues cells to appropriate interface after it breaks up the AAL-5 PDU into cells. – From ATM to Frame Relay or Ethernet port: The SAR reassembly unit launches the IP table lookup on the IP-DA address after forming the ATM-AAL-5 payload and examining the IP packet. This happens in the RxByte processor. The lookup response is received by reassembly CPRC unit. The descriptor is then enqueued to the queue associated with frame relay or ethernet port as may be the case. Later, frame relay or ethernet CPRC will fetch the payload from the offset in the descriptor and will encapsulate it. (Frame relay uses RFC 2427 for IP Encapsulation and Ethernet uses Type field in ethernet frame header as 0x0800 to indicate that IP is being carried within the packet).

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 28 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

SDP The SDP handles ATM cells as follows:

RxBit The initial processing of the incoming data stream involves: • Serial to Parallel Conversion: The OC-3c bit-wide data received on the line is converted from serial to parallel format for processing by the RxBit microsequencer. • SONET Frame Synchronization: The RxBit microcode determines SONET frame synchronization on the A1 and A2 bytes of the SONET frame and asserts a frame_sync pulse to the RxSonetFramer block. It maintains a state machine requiring two good frames to go in frame and 4 to go out of frame. • SONET Overhead and Pointer Processing: The RxSDP implements the OC-3c SONET frame processing in the RxSONET hardware block. This block interprets the SPE payload pointer, presents SONET defect and overhead information in registers accessible to the RC. • Cell Synchronization: The RxSDP implements the cell delineation algorithm as specified in ATM Forum UNI 3.1 including the HUNT, PRESYNC and SYNC state machine. This processing is performed in the RxSync microsequencer. While in SYNC, the payload of idle/unassigned cells and bad HEC cells are dropped and an indication is provided to the RxByte processor. • OAM CRC-10 Validation: All cells are checked for CRC-10 errors by the RxSync microsequencer and forwarded with an indication of failure or success.

RxSync • The RxSync processor receives bytes from the RxSonet block. It then validates the cells by means of Header Error Checksum (HEC) recognition. Immediately after a successful cell header recognition, RxSync checks to see if the cell is an unassignable/idle cell (VPI=0 and VCI=0), if so, the cell is discarded and no further processing is necessary.

RxByte • RxByte receives the valid ATM cells from the RxSync. It then pushes the VPI, VCI and CP ID through a shift and mask function that produces a virtual channel (VC) index. Next RxByte issues a lookup request to the TLU to translate the VC index into VC ingress control block and writes the VC index into extract space.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 29

• The SDP forms the VC index by concatenating the significant bits of VPI with the significant bits of VCI and then adding the result to a CP-unique base. In these CPRCs, the SDP’s RxByte serial processor silently consumes any intervening idle cells. • In our implementation, the upper 4 bits of the lookup indicates the port. The remaining 12 bits comprises the 6 bits each from VPI and VCI. The VCindex looks like - (CPID:VPI[5:0]:VCI [5:0]). 12 bits of VPI/VCI are used in the lookup currently. The assumption here is that ATM application uses VCI values contiguously starting at 1.

TxByte • The TxByte processor creates cells from the payload and the merge space it receives from the CPRC. Each cell is prepended with the ATM cell header which TxByte receives in merge space from CPRC. TxByte uses the length field to determine how many cells it will output. The AAL-5 PDU is segmented in the ATM cluster. • Addition of the HEC on the ATM Cell Header • SONET Frame and pointer generation • Calculation of partial CRCs for the AAL-5 Trailer • Performs TLU XOR command for AAL-5 CRC-32 Accumulation. • Addition of AAL-5 Trailer and Padding based upon information from the RC • CRC-10 Addition for OAM Cells

TxBit In addition to the processing performed by the TxByte Processor, the TxSDP performs the following OC-3c SONET functions to support bit-level transmit processing of ATM cells in SONET frames: • SONET Framing and Pointer Generation: The TxSONET block generates SONET frames and encapsulates ATM cells in these frames from the TxByte processor. • Parallel to Serial Conversion: The 8-bit data is converted from parallel to serial format for transmission by the TxSDP.

CPRCs 12 to 15 (SAR) The physical lines of these CPRCs are not used. These CPRCs are dedicated to SAR functionality. The segmentation is performed by CPRCs 12 and 13 and reassembly is performed by CPRCs 14 and 15.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 30 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

Segmentation processing Channel Processors CP12 and CP13 perform the segmentation activity. Each receiving Frame relay or Ethernet CP forwards (via the QMU) packets received on the Frame relay or ethernet ports to the SAR cluster for segmentation processing. Both CP12 and CP13 dequeue from the same input queue. A software token is used to ensure the dequeues are handled in an orderly fashion. Dequeued packets are transmitted out the CPs SDP, which is configured in byte-level recirculation mode. This SDPs TxByte serial processor turns the IP packet into an AAL5 PDU. The CPs RxByte serial processor receives the PDU via the SDPs recirculation path and forwards them to the ATM cell interface. TxByte precedes each recirculated PDU with a flag byte, a port byte, and an ATM header. The flag byte indicates to RxByte whether the block is destined for segmentation or reassembly processing. In this case, the flag will be set for segmentation. The next byte contains the output port number for the cell. The ATM header, which is common to all cells in the AAL5 PDU, is sent. Finally, the AAL5 PDU is sent. The first byte that RxByte receives after startup is a flag indicating that the processor should execute segmentation code. The second byte is the output port number of the first cell. The third byte is the first byte of the ATM header. RxByte must count through the 5Bytes of the cell header before it can find the AAL5 PDU. RxByte uses the Data9 signal to determine the end of the PDU. The applications segmentation processing is capable of segmenting two PDUs at a time.

Reassembly processing The ATM port (each of CP4 to CP7) is responsible for receiving ATM cells on the OC-3c line. Depending on the Virtual Connection Identifier, the cells are either switched as they are or reassembled. For re-assembly connections, each ATM port CP accumulates the cells of each AAL PDU into a single large buffer. The cells of an AAL-5 PDU are stored sparsely, that is, one 48Byte cell occupies each 64Byte stride within the buffer SDRAM space. This implementation is related to the design of the SDRAM memory controller. It would require two operations to write a 48Byte payload that straddles a 64Byte memory line in the SDRAM. At the expense of wasting 16Bytes per 64Bytes of SDRAM, only one operation is required and time is saved.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 31

When an ATM port CP receives the EOM cell, it fills out a QMU descriptor (along with a pointer to the AAL PDU) and forwards the descriptor to the AAL-5 receive activity running in the SAR cluster. It is expected that any cells that are not part of some AAL-5 PDU will be forwarded via the XP to the host processor for control plane processing. CP14 and CP15 in the SAR cluster performs the activity of AAL5 PDU receive processing. They recirculate AAL-5 PDUs through their SDPs to verify the CRC and length of the PDU. The SDPs RxByte serial processor also performs IP header processing and lookups in support of IP forwarding. Based on the IP lookup result, the SAR reassembly unit enqueues the descriptor to queue associated with the outgoing interface. In case of Ethernet and Framerelay, offset address of IP payload in DMEM is sent via descriptor. If outbound interface is also ATM then the descriptor is enqueued to segmentation CP to perform packet to cell conversion.

SDP The SDPs in the SAR cluster are configured for byte-level recirculation. The application’s segmentation processing is capable of segmenting two PDUs at a time. It cannot interleave cells from multiple PDUs. The processors in the SDP function as follows.

TxByte Segmentation unit: • The TxByte processor turns the IP packet into an AAL-5 PDU. TxByte precedes each recirculated PDU with a flag byte, a port byte, and an ATM header. • The flag byte indicates to RxByte whether the block is destined for segmentation or reassembly processing. In this case, the flag will be set for segmentation. The next byte contains the output port number for the cell. The ATM header, which is common to all cells in the AAL-5 PDU, is sent. Finally, the AAL5 PDU is sent. Reassembly Unit: • The TxByte processors first obtains the current operation, reassembly, and several other parameters from the CPRC via merge space. • TxByte sends a flag to RxByte to indicate reassembly will be performed. Then, it sends the number of bytes to RxByte as a 16bit integer value, so RxByte can know how many bytes to expect.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 32 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

• Using a cell count as a loop control, TxByte reads all payload but passes along only the cell contents, counting down the cells, passing on 48Bytes and discarding 16 alternately until all of the payload is processed.

RxByte Segmentation Unit: The RxByte processor receives the PDU via the SDPs recirculation path and forwards them to the ATM cell interface. The first byte that RxByte receives after startup is a flag indicating that the processor should execute segmentation code. The second byte is the output port number of the first cell. The third byte is the first byte of the ATM header. RxByte must count through the 5 bytes of the cell header before it can find the AAL5 PDU. RxByte uses the Data9 signal to determine the end of the PDU. Reassembly unit: The RxByte processor first obtains a flag from TxByte indicating that reassembly is to be performed. RxByte receives the number of bytes from TxByte. This byte count is a negative number suitable for use as a countdown value in an AllOnes() test loop. Using this counter, RxByte passes all the payload through to the RxCB DMA engine, and SDRAM. As the first bytes pass through, RxByte performs layer 2 or layer 3 processing to prepare the extract space with forwarding information. After all data bytes short of the AAL-5 CPCS-PDU trailer have been received, RxByte processes the trailer. The CSCS-UU and CPI bytes are discarded. (Future versions of this application might place them into extract space for further processing). The next two bytes received are the actual layer 2 or layer 3 packet length field, which is somewhat shorter than the number of bytes received at the head of the payload. This is because the number of bytes received at the head of the payload represents the length of the CPCS-PDU, which includes padding and the 8 byte CPCS-PDU trailer. The actual length received in the CPCS-PDU trailer represents the true length of the packet within the CPCS-PDU. RxByte must supply this piece of information to the CPRC via the CPRCs extract space. Note that RxByte has passed all AAL-5 CPCS-PDU padding through the RxCB DMA engine to the SDRAM buffer. ( These padding bytes are ignored later by the egress port that transmits the packet. This length field in extract space is the information needed by the egress port to transmit the packet in its correct length). The next four bytes after the packet length field are the 32bit CRC. These four bytes, like all the bytes before it, are accumulated into the RxByte’s CRC accumulator. A test on the

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 33

built-in condition, CRCerror, determines the validity of this CRC. A boolean value representing this validity is recorded in extract space..

TxBit and RxBit TxBit and RxBit level processors are not used since SAR uses byte level recirculation.

TLU The Table Lookup Unit (TLU) provides lookup table management. The TLU stores its table information in external SRAM that is managed by the TLU’s SRAM controller. The SwitchRouter application creates three different tables in the TLU for data path forwarding support.

ATM VC Table The ATM OC-3c port uses the cell forwarding table to determine the VC state for each cell received. The VC state determines whether the circuit is performing AAL-5 reassemblies, or plain cell forwarding. For reassembly operations, the VC state also provides the current buffer handle and offset for the current AAL-5 PDU reassembly. This table is implemented as a data table with 32 bit keys.

AAL5 VC table structure is as below- 31 ------24 23------16 15------8 7------0 index flags queueId offset bufHandle

IP Forwarding Table The AAL-5 reassembly process, ethernet, frame relay use the IP routing table to forward the IP packets they receive. The IP Routing table is used to resolve Layer 3 IP addresses into egress interfaces such as ethernet, frame relay or ATM. If the egress interface is Ethernet, it provides a new MAC DA for re-encapsulation during transmission. If the egress interface is ATM OC-3c, it provides a new VPI/VCI for addressing the cells, and a logical port number to forward the cells to for transmission. If the egress interface is frame relay, it provides the DLCI values to be used and the port number. The logical port number is translated into a queue number for forwarding a descriptor. For the C-5 NP, the IP Routing table is implemented in the TLU as a 16 bit Indexed Pointers table that resolves the first 16 bits of the IP address, and a VP Trie table that resolves the last 16 bits of the IP Address. The associated data of the entries in the IP routing table is

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 34 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

kept in a data table in the TLU. For the C-5e NP, the table is implemented as a LPM table with 32 bit keys.

Following is the IP route data structure that is used in IP lookup (16 bytes) 31 ------24 23------16 15------8 7------0 maskbits unused type ifIndex appData1 appData2 fabricId unused queueId

Bridge Forwarding Table The Bridge Address Table is used for resolving layer 2 MAC addresses into egress bridge ports for layer 2 forwarding. This is implemented in the TLU as a 96 bit keyed hash table that uses a Trie table for collision resolution and a key table to store the key and associated data.

Bridge address table structure is as below 31 ------24 23------16 15------8 7------0 queueId fabricId flags ageCount tableIndex usused unused

Table building in C-5 and C-5e The IP table, ATM VC table and Bridge Forwarding table for ethernet are built offline.

BMU The application allocates one buffer pool per Channel Processor. Each pool for Frame relay, Ethernet, ATM, and Reassembly SAR has 1024 buffers with a buffer size of 2048 bytes. Segmentation-SAR CPRCs have pools of 512 buffers each of size 2048 bytes. The ATM OC-3c port stores reassembled AAL-5 PDUs in a sparse format. That is, it stores the 48 bytes of payload from each cell on a 64 byte boundary. This leaves the last 16 bytes of each 64 byte block unused. The cost in memory usage is offset by a savings in processing time. This is because the storage of cell payload in a compact format would require an extra buffer write operation for each cell payload that would straddle a 64 byte boundary. Because half of the cell

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Resource Utilization 35

payloads would straddle a 64 byte boundary, the processing time due to payload write operations would be 50% higher.

QMU The application allocates 16 queues to each CPRC of 2 x Ethernet (CPRCs 0 and 1), 2 x Frame relay (CPRCs 8 and 9), 4 x ATM OC-3c (CPRCs 4-7); but the Ethernet, ATM, frame relay ports use only single queue i.e. base queue. Reassembly CPRCs (CPRCs 12-13) share a single queue and Segmentation CPRCs (CPRCs 14-15) share a single queue. During the Initialization phase of the application’s XP program, each CP receives an initialization descriptor from the XP. The XP also maintains one queue in which it receives cells/packets from ATM, SONET monitoring (Sonet error and so on), frame relay (signalling / Layer management, and so on), and the Ethernet (bridge learning, and so on) interfaces. The base queue number for a given CPRC is calculated as the CPRC number multiplied by 16. The base queue in the case of queue sharing CPRCs is obtained by using the lower CPRC number (among CPRCs that share queues) multiplied by 16. XP queue number is 320. Various descriptors used are described below.

IP Descritor Definition Ip Descriptor which is exchanged between Tx and Rx threads of CPRC has a structure layout as below

31 ------24 23------16 15------8 7------0 bufHandle length VNID_client appData1 appData2 appData3

The use of appData1 is going to be different depending on the egress port. Ethernet interfaces uses appData1 and appData2, whereas Ethernet and Frame relay uses only appData1 as below.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 36 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

appData1 & appData2 in Ethernet interface 31 ------24 23------16 15------8 7------0 appData1 (macHi address) unused appData2 (macLo)

appData1 in Frame Relay Interface indicates DLCI 31 ------24 23------16 15------8 7------0 Unused DLCI [9:8] DLCI [7:0]

appData1 in ATM indicates VcIndex 31 ------24 23------16 15------8 7------0 CPID VPI [5:0] ------VCI [5:0]

Control Descriptor used for handling signalling and Layer management DLCIs in 31 ------24 23------16 15------8 7------0 bufHandle length DLCI

Frame Relay

Control desciptor used to send control message from CPRC to XP in Ethernet 31 ------24 23------16 15------8 7------0 bufHandle command unused appData0 appData1 appData2 appData3

ICMP message descriptor used in MAC 31 ------24 23------16 15------8 7------0 bufHandle length VNID_Client appData1 appData2 appData3

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Design Issues 37

RAS AAL5 PDU descriptor used in ATM 31 ------24 23------16 15------8 7------0 bufHandle length VNID_Client (12 bit VNID + 4 bits client Id) appData1 appData2 appData3

FP This application doesn’t use the Fabric Processor at all.

Host Processor Interaction Offline Table Building Normally a host processor would maintain many of the tables that are used in the forwarding path. In order to simulate this, a Windows NT application is provided that builds tables, and adds and deletes entries while logging the activity to a file. A Perl script is supplied that can be used to translate the log file into an array of TLU SRAM entries defined in a tle_writes.h header file. The switchRouter application uses the array defined in the header file to initialize the TLU as though a host processor had created the tables and inserted some entries. The files used for creating and running this program are located in the .\offline\c5\ subdirectory under the apps\switchRouter\ directory.

Design Issues In the switchRouter application, CPRCs 0-1 are used as Ethernet 10/100 Mbps ports, CPRCs 4-7 as ATM OC-3c ports, CPRCs 8-9 as Frame relay and CPRCs 12-15 for SAR (Segmentation and Reassembly) processing. Extract space, Merge space and IP descriptor definitions are given below.

Extract Space Register Extract space is 128 bytes of byte-addressable memory that is accessible from the CPRC Definitions and the RxByte processor. The Extract Space is logically separated into two regions of 64 bytes each (16 four-byte registers). The CPRC software gets access to the correct 64-byte section of the memory by calling the C-5 system service function pduRxHeaderGet(). The RxByte processor only sees the 64-byte section associated with the extraction data scope that it is currently in. When in data scope 0, the RxByte processor sees the first 64 bytes (registers RxSDP0_Ext0 to RxSDP0_Ext15). When in data scope 1, the RxByte processor sees the second 64 bytes (registers RxSDP1_Ext0 to RxSDP1_Ext15). The SDP changes data scopes by setting the Avail bit in RxStatus0 or RxStatus1 to zero (0).

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 38 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

Extract Space Layout For the Ethernet interface the Extract Space looks like: Mac Header definitions

31 ------24 23------16 15------8 7------0 hdrStatus frameStatus rxPath protocol macType frameLength Unused priority badFrameCount vlanId macDaHi macDaLo Unused macSaHi macSaLo Unused ....IpHeader (32 bytes) ....

For ATM interface, the extract space looks like-

31 ------24 23------16 15------8 7------0 cellHeader vccIndex pduHeaderStatus congestionDrops crc10indicator encodePti camValue Unused

For SAR interfaces; there are two definitions of extract space which are used as unions. Segmentation unit uses segment extract space whereas reassembly uses reassembly extract space. Both of these definitions are given below: Segmentation Extract space layout-

31 ------24 23------16 15------8 7------0 sarFlag port Unused cellHeader pduHeaderStatus pduPayloadStatus congestionDrops

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Design Issues 39

Reassembly Extract space layout- 31 ------24 23------16 15------8 7------0 cpcsCrc cpcsPduLength sarFlag txClient Unused headerStatus ..IpHeader (32 bytes) ...

For frame relay interface, The extract space definition is below

Frame Relay Extract space layout- 31 ------24 23------16 15------8 7------0 dlci fecn becn de cr ea0 ea1 control nlpid IpHeader (Eight 32 bit words size) IpHeader (Eight 32 bit words size) IpHeader (Eight 32 bit words size) payloadLength protocol frameError dlciStatus congestionDrops

IP Header layout in Extract space 31 ------24 23------16 15------8 7------0 ipControl version IHL ToS Unused length identifier flags Unused fragmentOffset TTL protocol checkSum sourceAddress destinationAddress Unused

Merge Space Register Merge space is 128 bytes of byte-addressable memory that is accessible from the CPRC Definitions and SDP TxByte processor. These 128 bytes of Merge space are logically separated into two regions of 64 bytes. The CPRC accesses the correct 64-byte section of this memory by calling the CPI pduTxHeaderGet() function.

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 40 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

The TxByte processor only sees the 64-byte section associated with the transmit data scope in which it is located. When in data scope 0, the TxByte sees the first 64 bytes (registers TxSDP0_Merge0 to TxSDP0_Merge15). When in data scope 1, the TxByte sees the second 64 bytes (registers TxSDP1_Merge0 to TxSDP1_Merge15). The SDP changes data scope by setting the Avail bit in the TxStatus0 or TxStatus1 registers to a 1.

Merge Space Layout During runtime operation, the TxByte processor is the only C-5 NP resource reading from Merge Space and the CPRC is the only resource writing to Merge Space. The following are the structures that are mapped onto merge space for each of Frame relay, Ethernet, ATM, SAR interface.

For the Ethernet interface the Merge Space looks like- 31 ------24 23------16 15------8 7------0 pauseTime txAlgorithm dataLinkHdrSize macDaHi (higher 4 bytes) vlanTag macDaLo (lower 2 bytes) macSaHi (higher 4 bytes) Unused macSaLo (lower 2 bytes)

For ATM interface, the merge space layout is 31 ------24 23------16 15------8 7------0 cellHeader payloadLength txType (indicate is Unused non-AAL5, multiple AAL5 or OAM cells)

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Design Issues 41

For segmentation unit, the merge space definition is 31 ------24 23------16 15------8 7------0 sarFlag port UnUsed cellHeader aal5Uui aalCpi frameLength

For re-assembly unit, the merge space definition is 31 ------24 23------16 15------8 7------0 sarFlag txClient Unused cellCount byteCount

SAR unit checks the sarFlag; If false, It performs segmentation and if flag is true, it performs re-assembly.

Performance This application’s performance for each of the interfaces is computed to demonstrate the processing requirements.

Frame Relay interface operates on T3/E3 speed- 1 processor cycle = 5 ns (operating at 200 MHz clock) Packet size of 64 is considered for cycle budget computation

Calculations for T3 • T3 line speed - 44.736 Mbps • Number of frames on fully loaded T3 line in one second • Number of bytes in one second = (44.736 Mbps) / 8 b/B = 5.592 Mbytes/sec • Number of frames on fully loaded T3 line = (5.592 Mbytes/sec) / 64 bytes = 87375 frames/sec

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 42 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

• CPU cycles: – Mean time between two bytes on fully loaded T3 line = 1/(44.736 bits/usec) x (8 bits/Byte) = 178.826 ns/byte – Cycles per byte = (178.826 ns/byte) / (5 ns/cycle) = 35 clock cycles/Byte (rounded-off to integer value) – Cycles per bit = (35 cycles/Byte) / (8 bits/Byte) = 4 cycles/bit (rounded-off to integer value) – Cycles per frame (64 Bytes) = (35 cycles/Byte) x (64 Bytes/frame) = 2240 cycles/frame (minimum size packets)

Calculations for E3 • E3 line speed 34.304 Mbps • Number of frames on fully loaded E3 line in one second • Number of bytes in one second = (34.304 Mbps) / 8 b/B = 4.288 Mbytes/sec • Number of frames on fully loaded T3 line = (4.288 Mbytes/sec) / 64 bytes = 67000 frames/sec • CPU cycles: – Mean time between two bytes on fully loaded T3 line = 1/(34.304 bits/usec) x (8 bits/Byte) = 233.208 ns/byte – Cycles per byte = (233.308 ns/byte) / (5 ns/cycle) = 46 cycles/Byte (rounded-off to integer value) – Cycles per bit = (46 cycles/Byte) / (8 bits/Byte) = 5 cycles/bit (rounded-off to integer value) – Cycles per frame (64 Bytes) = (35 cycles/Byte) x (64 Bytes/frame) = 2944 cycles/frame minimum Conclusion: Considering the higher speed of T3, the following cycle budgets shall be met by the design explained in this document • Maximum cycles per bit at RxBit and TxBit: 4 cycles/bit • Maximum cycles per Byte at RxByte and TxByte: 32 cycles/Byte • Maximum cycles per frame at CPRC (Rx and Tx combined): 2240 cycles/frame

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Design Issues 43

ATM OC-3c Interface (operating at 155.52Mbps) The number of cells per second on the line is an important number in the evaluation of an ATM application for the C-5 NP. This number provides the starting point for sizing the internal resource demands within the C-5 NP.

Calculating the SONET OC-3c payload envelope size • SONET OC-3c frame size = 2,430Bytes (270 columns * 9 rows - of bytes arrangement) • SONET OC-3c section overhead = 81Bytes • path overhead = 9Bytes – payload envelop size = 2430 - 81 - 9 = 2,340Bytes per frame • Calculating the SONET OC-3c frames per second – 155,520,000 bps/8 bpB/2,430 Bpf = 8,000 frames per second • Calculating the OC-3c payload byte throughput – 2,340 Bpf * 8,000 fps = 18,720,000Bytes per second • Calculating the SONET OC-3c payload cell throughput: – ATM Cell size = 53 Bpcell – 18,720,000 Bps/53 Bpc = 353,207.547 cells per second The number 353,208 cells per second is a theoretical maximum. In practice most lines will be much lower. The following calculations show mean time between cells on a fully loaded line and cells on a fully loaded C-5 line Mean time between cells on a fully loaded line: 1 sec / 353,208cps = 2.8312 microseconds Worst case time between cells, back-to-back 155,520,000 bps/8bpB/53 bytes per cell = 366,792.5 cells/sec = 2.7263 microseconds

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 44 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

Ethernet 10/100 Mbps interface

Calculations for 10 Mbps

Number of frames on fully loaded 10 Mbps line in one second • Number of bytes in one second = (10 Mbps) / 8 b/B = 1.25 Mbytes/sec • Number of frames on fully loaded 10 Mbps line = (1.25 Mbytes/sec) / 64 bytes = 19531.25 ethernet frames/sec • CPU cycles: – Mean time between two bytes on fully loaded 10 Mbps line = 1/(10 bits/usec) x (8 bits/Byte) = 800 ns/byte – Cycles per byte = (800 ns/Byte) / (5 ns/cycle) = 160 cycles/Byte – Cycles per bit = (160 cycles/Byte) / (8 bits/Byte) = 20 cycles/bit – Cycles per frame (64 Bytes) = (160 cycles/Byte) x (64 Bytes/frame) = 10,240 cycles/frame minimum size frame.

Calculations for 100 Mbps

Number of frames on fully loaded 100 Mbps line in one second • Number of bytes in one second = (100 Mbps) / 8 b/B = 12.5 Mbytes/sec • Number of frames on fully loaded 100 Mbps line = (12.5 Mbytes/sec) / 64 bytes = 195312.5 ethernet frames/sec • CPU cycles: – Mean time between two bytes on fully loaded 100 Mbps line = 1/(100 bits/usec) x (8 bits/Byte) = 80 ns/byte – Cycles per byte = (80 ns/Byte) / (5 ns/cycle) = 16 cycles/Byte – Cycles per bit = (16 cycles/Byte) / (8 bits/Byte) = 2 cycles/bit – Cycles per frame (64 Bytes) = (16 cycles/Byte) x (64 Bytes/frame) = 1,024 cycles/frame minimum size frame.

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Supplied Application Files 45

Supplied Application Files Below is a list of the files that are a . part of this application and a brief description of their contents.

Interfaces Files that are used across processors are as follows:

FILE NAME LOCATION DESCRIPTION arpIf.h .../chip/np/inc Contains the interface for the ARP protocol for mac bridgeIf.h .../chip/np/inc Contains the public interface for the Bridge on the CPRC macIfCp.h .../chip/np/inc Contains the public declarations for the Ethernet MAC macIf.h .../chip/np/inc Contains struct declarations used by Mac ipIf.h .../chip/np/inc Declarations of IP related data structures. frIf.h .../chip/np/inc Declarations of FR related data structures atmIf.h .../chip/np/inc Declaration of structures used by ATM interface atmTableIf.h .../chip/np/inc Atm table related declarations ipTableIf.h .../chip/np/inc Ip table related declarations macIf.h .../chip/np/inc Ethernet related declarations macTableIf.h .../chip/np/inc Ethernet table related declarations sarIf.h .../chip/np/inc SAR related structure declaration sonetIf.h .../chip/np/inc SONET related structure declaration

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 46 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

XPRC Files that run on the XPRC are as follows:

FILE NAME LOCATION DESCRIPTION swrXp.h .../chip/np/xprc/inc Declares arrays for BMU parameters and bmu buffer sizes tle_writes.h .../chip/np/xprc/inc Create entries for routing table on ring bus; Offline table building code generates this file. atmConfigXp.h .../chip/np/xprc/inc Contains definitions for configuring ATM Ucode atmTableXp.h .../chip/np/xprc/inc Contains function prototypes of atm Table related functions swrXpMain.c .../chip/np/xprc/src Calls Kernel, Buffer & queue services initialization. Function calls to use the offline table building info for creation & initialisation of the IP routing table, bridge table and the ATM Table. Configuration of BMU & SDPs. Loading of CPRCs & sending initialization info to CPs. swrXpMainInit.c .../chip/np/xprc/src Calls Init2 Initialization. swrXpMainInit2.c .../chip/np/xprc/src Configuration of SDPs atmConfigCp.c .../chip/np/xprc/src atmUcodeConfigure() function definition in this file atmTableXp.c .../chip/np/xprc/src Atm VC table building function definitions

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Supplied Application Files 47

CPRC Files that run on the CPRC are as follows:

FILE NAME LOCATION DESCRIPTION anCp.h .../chip/np/cprc/inc Contains the interface for TBI Gigabit Ethernet autonegotiation queueManager.h .../chip/np/cprc/inc For queue sharing, status and forward declaration of functions. frIfCp.h .../chip/np/cprc/inc maintain statistical info ipChecksum.h .../chip/np/cprc/inc Definitions for IP Checksum support for CPRC frInit.h .../chip/np/cprc/inc Functions forward declarations frRx() frTx() etc. ipIfCp.h .../chip/np/cprc/inc Contains IP related data structures queueManagerInline.h .../chip/np/cprc/inc Contains Queue Manager Inline Function Definitions ipInitCp.h .../chip/np/cprc/inc Contains definitions for IP Initialization code atmTxCp.h .../chip/np/cprc/inc Contains definitions for ATM Transmit Processing ipLookupCp.h .../chip/np/cprc/inc Contains definitions for IP address lookup routines rasCp.h .../chip/np/cprc/inc Contains definitions for Reassembly functionality sarCpMain.h .../chip/np/cprc/inc Contains definition for SAR global variables segCp.h .../chip/np/cprc/inc Contains Definitions for Segmentation Functionality atmRxCp.h .../chip/np/cprc/inc Contains Definitions for ATM Receive Processing atmInitCp.h .../chip/np/cprc/inc Contains Definitions for ATM Initialization Code ipCp.h .../chip/np/cprc/inc Definitions for IP Support on CPRC errorHandling.h .../chip/np/cprc/inc This include file contains functions for retrieval of the error codes from hardware ipRxCp.h .../chip/np/cprc/inc Definition of inline functions which gets the table response and processes it

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 48 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

FILE NAME LOCATION DESCRIPTION macControlCp.c .../chip/np/cprc/src Contains the handling of control messages sent to the RC for the ethernet MAC application macInitCp.c .../chip/np/cprc/src Contains the implementation for the Ethernet MAC initialization and support macIrqHandlerCp.c .../chip/np/cprc/src Contains the CP interrupt handling code macPauseCp.c .../chip/np/cprc/src Contains the implementation for the Ethernet MAC Pause frame Rx handling macRxArpCp.c .../chip/np/cprc/src Contains the implementation for the Ethernet Mac ARP receive functions. macRxCp.c .../chip/np/cprc/src Contains the implementation for the Ethernet MAC receive functions macRxInternalCp.c .../chip/np/cprc/src This file contains the implementation for the Ethernet Mac internal receive functions macTxCp.c .../chip/np/cprc/src This file contains the implementation for the Ethernet MAC transmit functions macCpMain.c .../chip/np/cprc/src Contains CP initialization, receive & transmit threads creation for the ethernet application frRxCp.c .../chip/np/cprc/src Receive code for FR interface frTxCp.c .../chip/np/cprc/src Transmit code for FR interface ipInitCp.c .../chip/np/cprc/src Initializes the IP forwarding component on CPRC frCpMain.c .../chip/np/cprc/src Contains CP initialization, receive & transmit threads creation for the FR application frInitCp.c .../chip/np/cprc/src Frame relay receive and transmit thread initialization

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION Supplied Application Files 49

SDP Files that run on the SDP are as follows:

FILE NAME LOCATION DESCRIPTION ethernetDefinitions.h .../chip/np/sdp/inc Contains the union of the gigabit and 10/100 ethernet definitions ethernetParse.h .../chip/np/sdp/inc Ethernet parsing code included by 10/100 & gigabit Ethernet RX Byte codes ipFilterParse.h .../chip/np/sdp/inc Ip parsing code included by mac and sar code ipSwrFilterParse.h .../chip/np/sdp/inc Used in FR sdp byte code to parse the IP header enetRxBit.c .../chip/np/sdp/src Contains the SDP RX Bit Processor Ucode for 100 MBPS Ethernet enetRxBit10.c .../chip/np/sdp/src Contains the SDP RX Bit Processor Ucode for 10 MBPS Ethernet enetRxByte.c .../chip/np/sdp/src Contains the SDP RX Byte Processor Ucode for all speeds of Ethernet enetTxBit.c .../chip/np/sdp/src 100 Mbit half- / full- duplex ethernet TXBIT Processor microcode enetTxBit10.c .../chip/np/sdp/src Contains the SDP TX Bit Processor Ucode for 10 MBPS Ethernet enetTxByte.c .../chip/np/sdp/src Contains the SDP TX Byte Processor Ucode for all speeds of Ethernet sarRxByte.c .../chip/np/sdp/src SAR Ucode for the SDP RX Byte Processor sarTxByte.c .../chip/np/sdp/src ATM (OC3 SAR) Ucode for the SDP TX Byte Processor sarRxSync.c .../chip/np/sdp/src SAR Ucode for the SDP RX Sync Processor frRxByte.c .../chip/np/sdp/src Parses the FR, encapsulation hdr and IP header, does lookup and reads payload. frTxByte.c .../chip/np/sdp/src Transmits the FR packet with proper header addition and checksumming hdlcRxBit.c .../chip/np/sdp/src Gets the bit stream from Phy, does bit destuffing, byte forming and gives bytes to RxByte hdlcTxBit.c .../chip/np/sdp/src Convert byte stream to bit stream, bit stuffing and sends stream to Phy atmRxByte.c .../chip/np/sdp/src Contains atm RxByte Microcode

MOTOROLA GENERAL BUSINESS INFORMATION CSTAFRAE-UG/D REV 00 50 CHAPTER 1: FRAME RELAY TO ATM TO 10/100 ETHERNET SWITCH ROUTER APPLICATION GUIDE

FILE NAME LOCATION DESCRIPTION atmRxSync.c .../chip/np/sdp/src Contains atm RxSync Microcode atmTxByte.c .../chip/np/sdp/src Contains atm TxByte Microcode sarRxBit.c .../chip/np/sdp/src SAR RxBit Ucode acts like a wire sarRxByte.c .../chip/np/sdp/src SAR RxByte Ucode performs AAL5 Processing sarTxBit.c .../chip/np/sdp/src SAR TxBit Ucode acts like a wire sarTxByte.c .../chip/np/sdp/src SAR TxByte Ucode performs AAL5 Processing

Binaries Binary Files used for this application are as follows:

FILE NAME LOCATION DESCRIPTION SwitchRouter.pkg .../run/bin/$VARIANT Package file for this application

CSTAFRAE-UG/D REV 00 MOTOROLA GENERAL BUSINESS INFORMATION