DP83200SMT XLNT Manager FDDI Station Management (SMT) Software Support Package

October 1994

DP83200SMT XLNT Manager TM

FDDI Station Management
(SMT) Software Support Package
General Description
The XLNT ManagerTM Software Package completely imple-
ments all required and most optional FDDI SMT Protocol Features
functions. It comes complete with well documented source Y Implements all required and most optional FDDI Station
code written in the C programming language and an easy to Management Protocol functions
use Integration Guide. The source code is modular so that it Y Complete portability of the code to most hardware plat-
can be partitioned over multiple processors and can be forms
used in all FDDI applications including concentrators, and Y Direct interface with the FDDI Chip Set for compact
dual and single attach stations. The porting guide includes and efficient implementation
step by step instructions how to port the software to your Y Flexible architecture to allow code partitioning for single
hardware platform. XLNT Manager FDDI SMT Software is a
and multiple processors
product of XLNT Design Inc., and is made available to Na- Y Standard interface between SMT software and custom
tional Semiconductor FDDI customers through a sublicens-
management applications
ing agreement. Technical support is provided by National
Semiconductor’s fully trained FDDI Applications team.
Y Well documented source code (C Language)
XLNT Manager FDDI SMT Software combined with National Y Supports single and dual attach stations and concentra-
Semiconductor’s FDDI chip set provides a complete FDDI tors
solution. Y Operating System Independent
The software can easily be integrated into an operating en- Y Includes easy-to-use porting guide
vironment using minimal hardware and system support from
the operating environment. Custom Management services
can interface with the SMT software through a standard,
well defined, software interface. An integration sequence
example is included.

TL/F/11121 – 1
FIGURE 1. Station Management (SMT) Software Block Diagram

UNIXÉ is a registered trademark of AT&T Bell Laboratories.

XLNT ManagerTM is a trademark of XLNT Designs Incorporated.

C1995 National Semiconductor Corporation TL/F/11121 RRD-B30M105/Printed in U. S. A.

 Table of Contents
1.0 OVERVIEW
2.0 FUNCTIONAL DESCRIPTION
3.0 INTEGRATION PROCEDURE
4.0 SUBLICENSE AGREEMENT AND MAINTENANCE
5.0 TECHNICAL SUPPORT
1.0 Overview
One of the key areas in the FDDI standardization process
has been Station Management (SMT). The SMT document
provides the guidelines and protocols which can be used to
manage an FDDI network.
To ensure interoperability in a multi-vendor environment,
some of the protocols described in the SMT document are
mandatory. However, to facilitate the diverse network envi-
ronments envisioned for FDDI, many of the protocols de-
scribed are optional. Implementation of the optional proto-
cols will depend upon the application need.
The basic SMT functions required are:
Ð Fault management for high network availability
Ð Reliable error detection and recovery
Ð Access to networked resources
Ð Fast and reliable connection management procedure
Ð Management for multi-vendor networks
Ð Access to individual station information
Ð Flexible network configuration
FIGURE 2. Connection Services Process Block Diagram
2
2.0 Functional Description
The XLNT Manager Software Package completely imple-
ments all required and most optional FDDI SMT Protocol
Functions. The software package consists of three main
functional blocks as shown in Figure 1 . The three main func-
tional blocks are 1) Management Services Process (MSP),
2) the Frame Services Process (FSP) and 3) the Connection
Services Processes (CSP).
2.1 MANAGEMENT SERVICES PROCESS
The Management Services Process (MSP) processes infor-
mation in the Management Information Base (MIB). The
MIB is an information database which is defined by the FDDI
SMT Standard. It includes information about the status and
performance of a station. The information is collected from
the hardware and other processes and stored in a central
database. The Management Information Base (MIB) can be
accessed by a Management Application Process like the
Simple Network Management Protocol (SNMP) or by a re-
mote station over the network. The Management Services
Process maintains the MIB and provides a uniform interface
to the Management Application Process, the Frame Serv-
ices Process (FSP) and the Connection Services Process
(CSP).
2.2 FRAME SERVICES PROCESS
The Frame Services Process (FSP) implements the frame
based services defined by the FDDI SMT Protocol. The
FDDI SMT Protocol defines several different frame types
which are used to convey status and control information
between stations on the network. For example, Neighbor
Information Frames (NIFs) convey information about the
station to its neighbor. This information can be used in the
TL/F/11121 – 2

2.0 Functional Description (Continued)
development of a ring map. The Frame Services Process
responds to requests (from the Management Application
Process) to send frames. It also sends frames as required
by SMT and responds to SMT frames from other stations.
For more information on FDDI frame based services refer to
the ANSI/ISO FDDI SMT Documents.
2.3 CONNECTION SERVICES PROCESS
The Connection Services Process implements the Connec-
tion Management (CMT) and Ring Management (RMT)
functions of the FDDI SMT Protocol. The Connection Man-
agement (CMT) Protocol consists of three functional blocks
as shown in Figure 2 .
The three main functional blocks of the Connection Man-
agement (CMT) protocol are the Configuration Management
(CFM) block, the Physical Connection Management (PCM)
block and the Entity Co-ordination Management (ECM)
block.
The Physical Connection Management (PCM) block is re-
sponsible for establishing a photonic or electrical connec-
tion between two neighboring stations, signaling configura-
tion information and monitoring the link errors between sta-
tions. The PCM process interacts with the National
DP83256/56-AP/57 which performs the physical signaling
process and error monitoring functions.
The Configuration Management process controls the data
paths between MAC and PHY devices. This process inter-
acts with the configuration switch in the National
DP83256/56-AP/57 PLAYER a Device. It also interacts
with other SMT processes.
The Entity Co-ordination Management process controls the
optional optical by-pass switch and acts as a well defined
interface to the Management Services Process.
The primary function of the Ring Management process is to
detect duplicate addresses that would inhibit the ring from
becoming operational, and other network failures.
Implementation
The effective implementation of Station Management soft-
ware in a design is tied directly to the ability of the FDDI chip
set silicon to provide the appropriate hooks and manage-
ment information. The DP83200 FDDI Chip Set provides the
essential support for FDDI Station Management functions.
The PLAYER a Device and the MAC portion of the MACSI
Device support the Connection Mangement services and
the Ring Management service respectively. The system in-
terface portion of the MACSI Device provides separate Sta-
tion Management and data frame channels for the maxi-
mum support of the SMT Frame Services.
3.0 Integration Procedure
The following description presents a possible sequence for
integration of the XLNT Manager SMT software package
onto your system.
3
The steps described will, in general, have to be done to
integrate the SMT software package into a system, but
need not happen in the exact sequence given below.
# Hardware test
# Write network interface functions
# Define partitioning of SMT function
# Customize headers and initialization function
# Provide control interface
# Compile, link and test
# Integrate Management Application Process
3.1 HARDWARE TEST
It is imperative that the hardware platform is debugged be-
fore starting the XLNT Manager Software integration. Prop-
er data flow and timer operation is required before starting
the integration procedure. The time required to port the soft-
ware could be greatly extended if the hardware platform is
not fully debugged.
3.2 INTERFACE FUNCTIONS
A detailed description of how to write interface functions are
described in the XLNT Manager Integration Guide. A brief
explanation, with examples, follows here.
The SMT software uses a number of interface functions that
deal directly with the FDDI chip set hardware, provide timer
service to the FDDI functions and support transmission and
reception of SMT frames. Before writing and testing the
hardware interface, it is important to fully test the hardware
platform.
Example system functions:
uInt32 ReadSystemTimer (void)
void SetSystemTimer (uInt32 interval)
uInt StationPathTest (void)
void BypassRequest (uInt bypassState)
void ConfigureStation (uInt CFMÐstate)
Example PHY interface functions:
void TransmitPMD (uInt phyID, uInt state)
uInt16 ReadLineState (uInt phyID)
void SendLineState (uInt phyID, LineState ls)
Example MAC interface functions:
void MACResetRequest (uInt macID)
void SetBeacon (uInt macID, char beaconType,
LongAddr *DA, uInt infoLength, char *beaconInfo)
void BeaconRequest (uInt macID)
Write Interface Code
The majority of the integrator supplied code is in the inter-
face routines. The interface routines are those that directly
deal with hardware. Over four thousand lines of prototype
source code is supplied for these functions to aid the imple-
mentor.
The complexity of these functions varies significantly and
there is little correlation of the complexity of the function
with the amount of code. The most complex and important
implementor code is for frame transmission and reception.
This code is important because it provides the basic func-
tion of an FDDI attachment, moving data. SMT requires
3.0 Integration Procedure (Continued)
comparatively little frame transmission and reception and
performance of the SMT frame processes will not be critical
in most devices. An implementor supplied function that can
be fairly complex is the path test, though this is a logical
subset of a power on self test for the board. The majority of
the functions are simple and direct. These simple functions
include transmitting a line state, managing MAC frame
counters, and setting interrupt masks.
A few implementor provided functions are affected by the
options in the SMT Standard. Two examples are the method
to be used for scrubbing, and generation of data for link
confidence testing. If the implementor desires to use the
MAC in these cases, the interface code complexity will be
increased, since the MAC will need to be set up for genera-
tion of the desired data.
Many of these interface functions can be used in initial test-
ing of the board. Planning ahead and using the functions as
part of the basic hardware test plan can reduce the total
development time.

Example Section of Interface Function Code

TL/F/11121 – 3

The XLNT Manager Integration Guide includes detailed descriptions of all the functions.

4
3.0 Integration Procedure (Continued)
3.3 PARTITION OF SMT FUNCTION
The partitioning of SMT software is quite simple. In most
implementations, all SMT code will run on the same proces-
sor. If this is the case, there is no further effort associated
with this task. If the code is to be partitioned between proc-
essors, then communication routines need to be written to
transfer SMT signals between the different environments.
Defining the partition of the SMT function can be simple for
an adaptor card and less straight forward in a concentrator.
Implementors can partition the SMT functions between dif-
ferent processors. This includes the ability to separate Con-
nection Services from the rest of SMT. Those implementa-
tions partitioning SMT software onto multiple processors
must provide routines for communication between the SMT
functions in the separate environments.
3.4 CUSTOMIZATION OF HEADERS AND
INITIALIZATION FUNCTIONS
FDDI includes a large number of possible station types with
optional capability. The SMT software provides options sup-
ported by the code, and the SMT Standard. Examples, of
this customization include: number of MACs, number of
PHYs, default policies, and bypass relay present.
5
The next step is to customize header files. This includes
general customization like declaring whether the processor
uses big endian or little endian byte ordering.
Certain attributes need to be modified for differences in sta-
tion type, (e.g., SM-DAS, DM-DAS, bridge, etc). In some
cases, the implementation may be flexible, for example, an
optional external optical bypass relay. In these cases, the
customization of values is done in the initialization routines
so that the implementor can read hardware signals to deter-
mine the current configuration. (In the bypass case, inser-
tion of the connector for switching the bypass could be de-
tected through loopback between two pins on the connec-
tor.) Where the configuration is stable, the customization
can be done in header files or the initialization routine.
In SMT 7.3, the User must review approximately 10 attri-
butes for a node implementation with approximately 25 ad-
ditional attributes that the User may optionally review. In
some cases, these attributes occur multiple times (e.g., one
per PHY). In a few cases, the values of occurrences of an
attribute may differ (e.g., Requested Path for a MAC). These
attributes requiring review are well documented with de-
faults for the most common implementations included and
guidelines for selection of different values.
3.0 Integration Procedure (Continued)
Example Section of Initialization Code

TL/F/11121 – 5

6
3.0 Integration Procedure (Continued)
Write Interrupt Handler Code
The nature of this task is affected by the environment in
which the code is running. The functionality of an Interrupt
Handler may be included in the interrupt service routine or it
may be implemented as a separate function. There are sev-
eral interrupt classes used by SMT 7.3. Most of these
classes include only one interrupt (e.g., TVX expiration),
while others include virtually identical code for multiple inter-
rupts (e.g., MAC Counter overflow: FrameÐCt, ErrorÐCt,
etc.). National’s Chip Set includes additional interrupts that
are not used by SMT. These can be added as events that
are passed through the SMT code to the MAP interface.

Example Interrupt Handler Function

TL/F/11121 – 4

The XLNT Manager Integration Guide outlines the options and how to select them.

7
3.0 Integration Procedure (Continued)
3.5 PROVIDE CONTROL INTERFACE
The SMT software needs stimulus for beginning execution.
In initial test, the person testing the interface should have
access to basic SMT control. A simple connect and discon-
nect capability meets the minimum requirements. The trace
capabilities of the SMT software and other facilities provid-
ed through SMT can provide a more functional control inter-
face.
3.6 COMPILE, LINK AND TEST
After compiling and linking the code for MSP, CSP, or FSP,
the testing stage is entered. The number of stages included
in integration testing are largely influenced by the degree of
testing that the hardware has been subjected to prior to
integration, and whether the software is partitioned over
multiple processors. The software includes some basic
trace diagnostics to aid in integration testing. A detailed de-
scription of these functions is available in the XLNT Manag-
er Integration Guide.
3.7 INTEGRATE MANAGEMENT APPLICATION
PROCESS
The scope of defining an interface to an application process
can vary in degree of complexity. If no management agent
like SNMP is required the task is very simple. In some sta-
tions, the higher layer protocols used will also include a
Management Application Process. TCP/IP networks will
likely employ SNMP. The management agent requires ac-
cess to the management information base within the FDDI
attachment, and may require access to optional SMT
frames that the SMT software supports. Although not all
stations provide a formal management agent, the SMT soft-
ware requires some external control process to provide the
initial request for Connection Services and to handle cata-
strophic errors or conditions that the SMT components may
report. This simplifies implementation in basic stations, as
well as those that include an agent. A more detailed de-
scription of the procedure interface is provided in the XLNT
Manager Integration Guide.
3.8 TIMER REQUIREMENT
Although the SMT protocol may require timing many events
at once, the XLNT Manager handles this by using only two
timer interfaces. This includes one timer interface for CSP
and one for FSP. Each interface requires different timer
ranges and specifications.
8
For the CSP timer interface, XDI recommends a timer gran-
ularity of one-half ms or less (although the XLNT Manager
will work with larger granularity timers). The CSP timer re-
quirements range from 1 ms through 50 seconds with a tol-
erance of b0, a 1 ms. CSP needs read and write access to
the timer through the timer interface. It reads from the timer
to determine the time remaining before the next interval ex-
piration. It writes to the timer set the interval for the next
timer expiration.
At a minimum, the FSP timer interface requires the ability to
start a timer that generates a timer event once every two
seconds. The environment may handle this requirement us-
ing a timer or through a call-back mechanism. The timer
interface for FSP does not require read or write access to
the timer. It only requires that some entity add an event to
its timer queue periodically (e.g., once per second).
In addition to the two timer interfaces, SMT also requires a
time stamp function. The SMT standard specifies a time
stamp granularity of 8 ms or less. Depending on the system
environment, the User could implement the time stamp us-
ing a system clock tick, a system time of day function, or
using the timer supporting the CSP and FSP timer interfac-
es.
4.0 Sublicense Agreement
and Maintenance
XLNT Manager is a product of XLNT Designs Inc. National
Semiconductor sublicenses XLNT Manager source code to
its customers. A sublicense agreement is available on re-
quest. Maintenance upgrades are available under the terms
of the optional maintenance agreement. A maintenance
agreement is available on request.
5.0 Technical Support
XLNT Manager software written in the C programming lan-
guage comes complete with an easy to use integration
guide. Most engineers can port XLNT Manager software to
their hardware platform in less than six weeks. A detailed
description of the integration procedures are outlined in the
Integration Guide. Most customers can proceed with little
assistance but should the need arise, National’s application
staff can answer your technical questions.
9
DP83200SMT XLNT Manager FDDI Station Management (SMT) Software Support Package

LIFE SUPPORT POLICY

NATIONAL’S PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE SUPPORT
DEVICES OR SYSTEMS WITHOUT THE EXPRESS WRITTEN APPROVAL OF THE PRESIDENT OF NATIONAL
SEMICONDUCTOR CORPORATION. As used herein:

1. Life support devices or systems are devices or 2. A critical component is any component of a life
systems which, (a) are intended for surgical implant support device or system whose failure to perform can
into the body, or (b) support or sustain life, and whose be reasonably expected to cause the failure of the life
failure to perform, when properly used in accordance support device or system, or to affect its safety or
with instructions for use provided in the labeling, can effectiveness.
be reasonably expected to result in a significant injury
to the user.

National Semiconductor National Semiconductor National Semiconductor National Semiconductor

Corporation Europe Hong Kong Ltd. Japan Ltd.
1111 West Bardin Road Fax: (a49) 0-180-530 85 86 13th Floor, Straight Block, Tel: 81-043-299-2309
Arlington, TX 76017 Email: cnjwge @ tevm2.nsc.com Ocean Centre, 5 Canton Rd. Fax: 81-043-299-2408
Tel: 1(800) 272-9959 Deutsch Tel: (a49) 0-180-530 85 85 Tsimshatsui, Kowloon
Fax: 1(800) 737-7018 English Tel: (a49) 0-180-532 78 32 Hong Kong
Fran3ais Tel: (a49) 0-180-532 93 58 Tel: (852) 2737-1600
Italiano Tel: (a49) 0-180-534 16 80 Fax: (852) 2736-9960

National does not assume any responsibility for use of any circuitry described, no circuit patent licenses are implied and National reserves the right at any time without notice to change said circuitry and specifications.