HDLC-Frame Protocol User’s Guide
Edition 4
HP 9000 Networking
Manufacturing Part Number: Z7487-90005
E0400
© Copyright 2000 Hewlett-Packard Company
2
Legal Notices
The information in this document is subject to change without notice.
Hewlett-Packard makes no warranty of any kind with regard to this
manual, including, but not limited to, the implied warranties of
merchantability and fitness for a particular purpose. Hewlett-Packard
shall not be held liable for errors contained herein or direct, indirect,
special, incidental or consequential damages in connection with the
furnishing, performance, or use of this material.
Warranty. A copy of the specific warranty terms applicable to your
Hewlett- Packard product and replacement parts can be obtained from
your local Sales and Service Office.
Restricted Rights Legend. Use, duplication or disclosure by the U.S.
Government is subject to restrictions as set forth in subparagraph (c) (1)
(ii) of the Rights in Technical Data and Computer Software clause at
DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and
(c) (2) of the Commercial Computer Software Restricted Rights clause at
FAR 52.227-19 for other agencies.
HEWLETT-PACKARD COMPANY 3000 Hanover Street Palo Alto,
California 94304 U.S.A.
Use of this manual and flexible disk(s) or tape cartridge(s) supplied for
this pack is restricted to thi s product only.Additional copies of the
programs may be made for security and back-up purposes only. Resale of
the programs in their present form or with alterations, is expressly
prohibited.
Copyright Notices. © copyright 1983-98 Hewlett-Packard Company, all
rights reserved.
Reproduction, adaptation, or translation of this document without prior
written permission is prohibited, except as allowed under the copyright
laws.
© copyright 1979, 1980, 1983, 1985-93 Regents of the University of
California
3
This s oftware is based in part on the Fourth Berkeley Software
Distribution under license from the Regents of the University of
California.
© copyright 1980, 1984, 1986 Novell, Inc.
© copyright 1986-1992 Sun Microsystems, Inc.
© copyright 1985-86, 1988 Massachusetts Institute of Technology.
© copyright 1989-93 The Open Software Foundation, Inc.
© copyright 1986 Digital Equipment Corporation.
© copyright 1990 Motorola, Inc.
© copyright 1990, 1991, 1992 Cornell University
© copyright 1989-1991 The University of Maryland
© copyright 1988 Carnegie Mellon University
© copyright 1989-1997 Data Connection Limited
Trademark Notices UNIX is a registered trademark in the United
States and other countries, licensed exclusively through X/Open
Company Limited.
X Window System is a trademark of the Massachusetts Institute of
Technology.
MS-DOS and Microsoft are U.S. registered trademarks of Microsoft
Corporation.
OSF/Motif is a trademark of the Open Software Foundation, Inc. in the
U.S. and other countries.
4
Printing History
The manual publishing date and part number indicate its current
edition. The publishing date will change when a new edition is
published. Minor changes may bemade withoutchanging the publishing
date. The manual part number will change when extensive changes are
made.
Manual updates may be issued between editions to correct errors or
document product changes. Toe nsure that you receive the updated or
new editions, you should subscribe to the appropriate product support
service.See your HP sales representative for details.
First Edition November 1996 Release B.02.22 & 23
(HP-UX 10.10 & 10.20
Second Edition June 1997 Release B.02.39 (HP-UX 10.10
Release B.02.40 (HP-UX 10.20
Third Edition October 1998 Release B.03.01 (HP-UX 11.0
Fourth Edition April2000 Release B.03.10 (HP-UX 11.0)
5
6
Preface
The HDLC.FRAME Protocol Product is used in conjunction with
Hewlett-Packard’s Advanced Communications Controller (ACC) product.
This manual explains installing the HDLC.FRAME protocol module and
configuring the module into the ACC product.
Organization
This manual contains the following chapters and appendix:
Chapter 1 Chapter 1 , “Overview,” presents an overview of the
features provided by theHDLC.FRAME Protocol
product.
Chapter 2
Chapter 3
Chapter 4
Appendix A
Appendix B
Chapter 2 , “Software Installation Note,”
automatic installation of HDLC.FRAME protocol.
Chapter 3 , “Using HDLC.FRAME Protocol,”
information about using the HDLC.FRAME protocol.
Chapter 4 , “Protocol Specific Configuration,”
HDLC.FRAME specific configuration information.
Appendix A , “Sample Configuration File,”
listing of the sample configuration files provided with this
product.
Appendix B , “Using the SS7 Mode Feature,”
how the SSU mode feature of the HDLC.FRAME protocol
product.
describes the
contains
contains
contains a
describes
7
8
Contents
1. Overview
Introduction................................................14
ProductFeatures............................................14
SupportedDevices...........................................15
ModesofOperation..........................................15
DataRules ...............................................15
FilesProvided ..............................................16
2. Software Installation Note
Notice.....................................................18
3. Using HDLC.FRAME Protocol
Introduction................................................20
ApplicationMessageHeaders..................................20
TimeoutProcessing..........................................21
ApplicationControlRequests..................................21
LinkStateIndications........................................22
Non-E1/T1ACC...........................................22
E1/T1ACC...............................................22
RequestSpecificProcessing...................................24
ControlRequests ..........................................24
StatusandErrorMessages....................................25
TransmitCompletionStatusCodes ...........................25
Non-E1/T1Interface......................................26
E1/T1interface..........................................27
UnsolicitedStatusMessages.................................28
Z7340AACCInterface....................................28
9
Contents
OtherNon-E1/T1interfaces...............................29
E1/T1interface..........................................30
ReceiveCompletionStatusCodes............................31
4. Protocol Specific Configuration
Introduction...............................................34
InterfaceDefinitions ........................................34
PortDefinitions............................................ 35
TerminalDefinitions ........................................36
Non-E1/T1HDLC.FRAMEConfigurationValues ................. 38
PollWord................................................38
AZR - (Z7340A only) Analyzer terminal for received data . . . . . . . 38
AZT - (Z7340A only) Analyzer terminal for transmitted data . . . . 38
CWEN - Enable the use of formatted Control Write requests . . . . 38
RSIG - Report status on CTS or DCD signal state change . . . . . . . 38
DSIG-Godownonlossofsignal ...........................39
RTS-ControltheRTSsignalontransmittedframes...........39
SelectWord.............................................. 39
BADFR-Badframecompletion............................ 39
ProtocolOptionWord..................................... 39
E1/T1HDLC.FRAMEConfigurationValues .....................40
PollWord................................................40
FISUFlags-FISUinter-frameflagcount(SS7only) ..........40
SS7-EnableSS7processing............................... 40
AZT-Analyzerterminalfortransmitteddata................. 40
AZR-Analyzerterminalforreceiveddata.................... 40
SelectWord.............................................. 41
Discard-rate-Received FISU or LSSU frames to discard (SS7 only)41
Bulk-Rx-Receivedframegroupprocessing(SS7only)..........41
10
Contents
ProtocolOptionWord.......................................41
PredefinedConfigurationValues..............................41
A. Sample Configuration File
TerminalDefinition..........................................44
B. Using the SS7 Mode Feature
TransmittingFrames ........................................46
ReceivingFrames ...........................................47
11
Contents
12
1 Overview
13
Overview
Introduction
Introduction
The HDLC.FRAME Protocol is part of the Advanced Communications
Controller (ACC) family of products This manual provides configuration
information that is specific to that protocol.
There are differences in the use of the HDLC.FRAME protocol, which
depend on the type of physical interface in use. The physical interface
types fall into one of two categories. These are “E1/T1” and all other
types (for example “RS232” or”X.21”). Throughout this document these
categories are referred to as E1/T1 or non-E1/T1.
Product Features
The HDLC.FRAME protocol adds HDLC framing (including the
checksum) to outgoing messages and strips the HDLC framing
(including the checksum)from incoming messages. The HDLC.FRAME
protocol performs frame checksum processing.
The HDLC.FRAME protocol is fully defined in the following ISO
standards document:
ISO 3309 HDLC Procedures - Frame Structure
Fifth edition 1993-12-15
Reference number ISO/IEC 3309:1993(E)
14 Chapter1
Overview
Supported Devices
Supported Devices
The HDLC.FRAME protocol implementation maybe used to supportany
protocol which requires HDLC framing conforming to the above
published standard at the physical layer.
Modes of Operation
The HDLC.FRAME implementation supports a single mode of operation:
• Two way continuous communication (normal)
Data Rules
This release of the HDLC.FRAME protocol product is qualifiedfor use at
line speeds up to the limit set by the interface card hardware.
Chapter 1 15
Overview
Files Provided
Files Provided
The HDLC.FRAME protocol is provided with all pre-loaded firmware
files as pa rt of the ACC Base Software product.
The HDLC.FRAME protocol may also be used on the same ACC card as
other protocols.
For information on installing the ACC product, how to load the
relocatable firmware files,and how to start upthe ACC Subsystem, refer
to the ACC Installation and Configuration Guide.
For information on using the utilities related to the ACC products, refer
to the ACC Utilities Reference Manual.
Forinformation on usingthe ZCOMProgrammatic Interface,refer tothe
ACC Programmers’ Reference Guide.
For information on error messages related to the ACC products, refer to
the ACC Error Guide.
16 Chapter1
2 Software Installation Note
17
Software Installation Note
Notice
Notice
This chapter is only included to inform the reader that there are no
specific steps or procedures involved in the installation of the Level 1
Framing protocol HDLC.FRAME. When the ACC Base System software
is installed, this protocol is included in that installation.
18 Chapter2
3 Using HDLC.FRAME Protocol
19
Using HDLC.FRAME Protocol
Introduction
Introduction
For a complete description of the communicationsformats and protocol
disciplines, the reader is referred to the ISO standard mentioned in the
first chapter of thismanual.
The HDLC.FRAME protocol is a non-polled, bit oriented protocol. Each
unit transmitted over a Level 1 link is termed a frame. A frame consists
of the following components:
• Opening flag (one byte binary 01111110)
• Data (supplied by higher layer)
• Frame check sequence (2 bytes)
• Closing flag (one byte binary 01111110).
A number of parameters can be configured to control the operation of
ports which make use of the HDLC.FRAME protocol. These parameters
are f ully described in Chapter 4 , “Protocol Specific Configuration.”
Application Message Headers
The HDLC.FRAME protocol does not use application message headers.
Both transmitted and received messages contain only the data portion of
frames sent across the link. The protocol adds leading and trailing flags
and the checksum to transmitted messages, and removes the same from
received messages.
20 Chapter3
Using HDLC.FRAME Protocol
Timeout Processing
Timeout Processing
There are no user-configurable timeouts in use with the HDLC.FRAME
protocol.
Application Control Requests
All HDLC.FRAME terminals must be enabled prior to sending and
receiving messages.
The activate and deactivate requests have no effect on the
HDLC.FRAME protocol.
Chapter 3 21
Using HDLC.FRAME Protocol
Link State Indications
Link State Indications
Non-E1/T1 ACC
If the “DSIG” configuration bit is set then the UP/DOWN state of the
HDLC.FRAME terminal i s dependent on the state of the CTS and DCD
signals. When CTS and DCD are b oth asserted, the HDLC.FRAME
terminal is UP.
If the “DSIG” configuration bit is clear then the state of the
HDLC.FRAME terminalis not dependent on the state of the CTS and
DCD signals. In this case the HDLC.FRAME terminal is always UP.
E1/T1 ACC
The E1/T1 ACC determinesthe UP/DOWN state of each port bythe state
of the frame synchronization mechanism. When the hardware
establishes E1 or T1 frame synchronization on a port then all
HDLC.FRAME terminals on that port are immediately placed in the UP
state. If the hardware cannot detect received E1 or T1 frames without
error, then all HDLC.FRAME terminals on that port are placed in the
DOWN state. The sensitivity of the ACC to errors on the E1 or T1 lines is
affected by the “qdown” port option.
The “qdown” port configuration option is documented in the ACC
Utilities Guide chapter on TTGEN. It affects the way an E1 or T1 port is
set DOWN when frame synchronization is lost.
• Withoutthe “qdown”option, the frame synchronization of an E1or T1
port is checked every second. If frame synchronization is lost at 4
consecutive checkpoints, then the port is set DOWN. This ensures
that higher level protocols are not disturbed by transient errors on
the line. This is the recommended configuration.
22 Chapter3
Using HDLC.FRAME Protocol
Link State Indications
• If the “qdown” option is set then the port is set DOWN whenever the
hardware detects a loss of synchronization. It is possible for the
hardware to alternately re-establish and lose synchronization
extremely rapidly with a poor quality line, making it difficult for
higher layer protocols to operate. The “qdown”bit should beused only
where line quality is known to be very good and with upper layer
protocols that need immediate notification of any line problems (SS7
for example).
If an E1/T1 port is configured for external clock, and has no cable
connected,itispossibleforthehardwaretodetectframingdueto
crosstalk from other E1/T1 lines,so HDLC.FRAMEterminals on the port
may be indicated as UP.
Chapter 3 23
Using HDLC.FRAME Protocol
Request Specific Processing
Request Specific Processing
Control Requests
All control writes to this protocol share a common format.The first four
bytesaredefinedasaheader
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Control Code Control Length
Packet Length(0)
Control Code Defines the action t o be taken by this request.
Control Length The byte length of the data for this control request.
This data immediately follows the header.
Packet Length Some protocols allow packet data (data to be
transmittedoverthewire)tobepassedtoacontrol
write following the control request data. For this
protocol, these two bytes must be zero because the
protocol does not allow packet data within a control
write.
This protocol supports the following Control Code:
5 CW_STATS Send IO_STATS status message
This control write triggers the protocol to send an
IO_STATS status message. For the format of this
message, see the section on “Status and Error
Messages”. The control length is zero.
Note that the Non-E1/T1 version of this protocol must have Control
Write processing enabled, in order to be able to process Control Write
requests. See the “Terminal Definitions” section of Chapter 4 , “Protocol
Specific Configuration,” for details.
24 Chapter3
Using HDLC.FRAME Protocol
Status and Error Messages
Status and Error Messages
Error conditions and important events are reported to the application
program through three kinds of status codes. These are “Transmit
completion”, “Unsolicited” and “Receive completion” status codes.
The defines for these status codes are located in
/usr/include/zcomstatus.h and /usr/include/zx25status.h.
Transmit Completion Status Codes
Transmit completion status is generated by the protocol on all transmit
messages. Depending on the mode parameter selected when using the
zsend call, the application will see either No transmit response
messages, Error responses only, or All transmit response messages. The
status code contained in the header of these messages indicates either
the successful transmission of t he message, or the reason why it could
not be transmitted.
Chapter 3 25
Using HDLC.FRAME Protocol
Status and Error Messages
Non-E1/T1 Interface
The following transmitcompletion status codes may be generatedby the
HDLC.FRAME protocol on a non-E1/T1 interface.
Table 3-1 Non-E1/T1 Interface Transmit Completion Status Codes
Transmit
Status Code
IO_OK No error detected.
IO_DSBL Terminal disabled.
IO_LONG_MSG
(Z7340A only)
IO_SHRT_MSG
(Z7340A only)
IO_TX_TMOUT Cable or local modem fault.
Description
This message was successfully transmitted to the
receiving station.
Messages cannot be transmitted by a disabled terminal.
There is a limit to the number of buffers which may be
used for a single transmit frame. If this limit is exceeded,
the frame is flushed with this status code, and is not
transmitted. Note: The Z7340A card has a configurable
buffer size. A buffer size of 128 bytes or larger will
prevent this problem from occurring.
A zero length frame cannotbe transmitted by the Z7340A
ACC.
This message cannot be sent or acknowledged because of
a bad clock or modem signal.
26 Chapter3
Using HDLC.FRAME Protocol
Status and Error Messages
E1/T1 interface
The following transmitcompletion status codes may be generatedby the
HDLC.FRAMEprotocol on an E1/T1 interface.
Table 3-2 E1/T1 Interface Transmit Completion Status Codes
Transmit
Status Code
IO_OK No error detected.
IO_DSBL T erminal disabled.
IO_DOWN Terminal down.
IO_LONG_MSG There is a limit to the number of buffers which may be
IO_TX_URUN Transmit underrun.
Description
This message was successfully transmitted to the
receiving station.
Messages cannot be transmitted by a disabled terminal.
This message could not be sent because the physical
interface is not operational (usually when frame
synchronization has been lost).
used for a single transmit frame. If this limit is exceeded,
the frame is flushed with this status code, and is not
transmitted. Note: This ACC has a configurable buffer
size and a buffer size o f 128 bytes or larger will prevent
this problem from occurring.
This frame could not be transmitted at this time due to
excessive loading of the interface card.
Chapter 3 27
Using HDLC.FRAME Protocol
Status and Error Messages
Unsolicited Status Messages
The unsolicited status messages (mrq.mrqcode = =
ZCOM_MRQCODE_STATUS) are used to inform the application
program of events which occur affecting communications with theremote
station. The status code “No error detected” is used to inform the
application that the remote station is communicating normally. This
could occur when an terminal has been enabled, or after an error
condition has been cleared.
For status codes within request code 5 (unsolicited status report) bit 7
willbesettoindicatetheUP/DOWNstateoftheterminalaftertheevent
whichcaused the statusreport. Bit 7 willbe set if the terminal state was
DOWN, and it will be clear if the terminal state was UP. An unsolicited
status report of zero (UP, no error detected) is used to indicate the
terminal has just come UP after being DOWN.
Z7340A ACC Interface
The following unsolicited status codes may be received by an application
program from the HDLC.FRAME protocol on a Z7340A ACC interface.
Table 3-3 Z7340A Interface Unsolicited Status Codes
Unsolicited
Status Code
IO_OK No error detected.
IO_DSBL Terminal Disabled
ST25XDCD Loss of DCD signal
ST25XCTS Loss of CTS signal
IO_STATS This message is sent in response to a CW_STATScontrol
IO_ALRDY_ENBL An enable request is received, while HDLC.FRAME is
28 Chapter3
Description
Normal communications have been established or
resumed.
write. The data buffer contains a x25l2stat_type structure
(defined in zcomx25.h)
already enabled. No action is taken and this unsolicited
status code is returnedwith the UP/DOWN bit set to
reflect the state of the port.
Using HDLC.FRAME Protocol
Status and Error Messages
Table 3-3 Z7340A Interface Unsolicited Status Codes
Unsolicited
Status Code
IO_ALRDY_DSBL A disable request is received, while HDLC .FRAME is
IO_RX_BUF Either the port or the card as a whole is running low on
Other Non-E1/T1 interfaces
The following unsolicited status codes may be received by an application
program from the HDLC.FRAME protocol on a non-E1/T1 interface.
Table 3-4 Other Non-E1/T1 Interface Unsolicited Status Codes
Unsolicited
Status Code
IO_OK No error detected.
ST25DSBL Terminal Disabled
Description
already disabled. No action is taken.
free buffers. Some tuning of the ACC configurable
parameters may be required. Refer to the section on
“TTGEN” in the ACC Utilities Reference Guide.
Description
Normal communications have been established or
resumed.
ST25XDCD Loss of DCD signal
ST25XCTS Loss of CTS signal
IO_STATS This message is sent in response to a
write. The data buffer contains a
structure (defined in
Chapter 3 29
zcomx25.h
CW_STATS
x25l2stat_type
)
control
Using HDLC.FRAME Protocol
Status and Error Messages
E1/T1 interface
The following unsolicited status codes may be received by an application
program from the HDLC.FRAME protocol on an E1/T1 interface.
Table 3-5 E1/T1 Interface Unsolicited Status Codes
Unsolicited
Status Code
IO_OK No error detected.
IO_DSBL Terminal Disabled
IO_TX_TMOUT Cable or lo cal modem fault.
IO_LONG_MSG Frame too long (SS7 only)
IO_RX_BUF No receive buffers
IO_ALRDY_ENBL Terminal already enabled
Description
Normal communications have been established or
resumed.
The physical connection to the remote device has been
lost.
HDLC.FRAME has entered octet counting mode.
The number of available free buffers or message headers
on the interface card is dangerously low.
An enable request was received for an HDLC.FRAME
terminal which was already enabled.
IO_ALRDY_DSBL Terminal already disabled
A disable request was received for an HDLC.FRAME
terminal which was already disabled.
IO_STATS This message is sent in response to a
write. The data buffer contains an
structure (defined in
structure is the same as the
mentioned above, except that it has some additional
fields.
30 Chapter3
fw_types.h
x25l2stat_type
CW_STATS
l2stat_type
l2stat_type
). The
structure
control
Using HDLC.FRAME Protocol
Status and Error Messages
Receive Completion Status Codes
If the BADFR bitis not set in theconfiguration, allmessages receivedby
the application from HDLC.FRAME will have a status code of zero.
Received messages that have errors will not be returned by the protocol.
See Chapter 4 , “Protocol Specific Configuration.”
If the BADFR bit is set, all messages, regardless of whether or not they
have errors, are received by the application from HDLC.FRAME. In this
case the following status codes are used.
Receive
Status Code
IO_OK No error detected.
IO_LONG_MSG
(not Z7340A)
IO_RX_BUF
(not Z7340A)
IO_BCC_ERR BCC or CRC error.
IO_RX_ORUN
(not Z7340A)
IO_PARITY Parity or framing error.
Description
Normal communications have been established or
resumed.
Message too long
A received frame was too large to be buffered.
No receive buffers.
The protocol has run out of free receive buffers.
A received frame contained an incorrect CRC.
Receive overrun.
The processing of a received frame could not be
completed in time.
1
A framing error had been detected by the frame receiver.
1. non-E1/T1 interface only
Chapter 3 31
Using HDLC.FRAME Protocol
Status and Error Messages
32 Chapter3
4 Protocol Specific Configuration
33
Protocol Specific Configuration
Introduction
Introduction
This chapter provides specific information on preparing the network
configuration file when HDLC.FRAME is to be used.
ThepartsofthenetworkconfigurationfilerelevanttoHDLC.FRAME
are:
• Interface definitions
• Port definitions
• Terminal definitions
Interface Definitions
Any card with HDLC.FRAME t erminals configured, must have an
interface definition line in the network configuration file. This serves to
associate a card (or mux)number withthe physicallocation of thecard in
the machine, and also specifies the firmware to be downloaded (one file
only) to the card when it is started up.
A few sample interface definitions are as follows:
Z7200A 00 0:4 /opt/acc/z7200a/loopback.zabs
The “z7200a” part will be different depending on the ACC card used. It
should be set to “z7400a” for EISA cards, for example.
34 Chapter4
Protocol Specific Configuration
Port Definitions
Port Definitions
The ports used must be defined as o perating in SDLCmode. They may be
defined with either an external (modem supplied) clock, or an internal
(Card supplied) clock. With an external clock, the speed is for
documentation purposes only, and is not used b y the ZCOM system.
The clock multiplier should be x1, and the encoding mode may be NRZ or
NRZI.
A sample port definition is as follows:
Port 01:4 9600 Ext SDLC x1 NRZ
Refer to the ACC Utilities Reference Guide Section on ttgen for more
information on the port definition.
Chapter 4 35
Protocol Specific Configuration
Terminal Definitions
Terminal Definitions
Only one HDLC.FRAME terminal may be configured on each port (or in
the case of an E1/T1 interface, on each subchannel). The only exception
to this rule is that two Protocol Analyzer terminals (one for transmitted
and one for received data) may also be configured on a subchannel.
The terminal definition has the following general format:
Term zlu card:port:subc type poll select application_data name
ZLU This number (120 in the example) assigns a unique
reference number for this terminal.
Card:port:subc The port assigned must be configured as in “Port
Definitions” above and the Card must have the
appropriate HDLC.FRAME firmware available. The
subsc parameter is used on E1/T1 cards and must have
been defined in the Subchannel Definition section.
type This name defines a device type which is used with the
HDLC.FRAME protocol. It must be set to
“HDLC.FRAME”.
poll The format of this parameter is described in the “E1/T1
HDLC.FRAME Configuration Values” section of this
chapter.
select The individualparameters containedin the select word
are defined and described in a later section of this
chapter.
application_data Five 16 bit parameters are required here, the first of
which is known as the “Application number”. This
number is used by applications to locate terminal
devices, avoiding the need for physical configuration
data, such as card and port numbers, in the
application. The Application Number should be greater
than 1000 for customer applications. The remaining
four parameters may be used for any purpose. All five
parameters are available to the application in the
Logical Terminal table, which can be read by using the
“zinfo()” library function.
36 Chapter4
Protocol Specific Configuration
Terminal Definitions
name A description of the HDLC.FRAME terminal,
preferably including a reference to the location of the
remote end of the link. This field is used in some
ZMNTR displays. It may also be accessed
programmatically from the Logical Terminal table
using the “zinfo()” library function.
An example Level 1 terminal definition line follows:
Term 120 1:6 HDLC.FRAME 0000H 0000H 10000000”HDLC device port 6”
This terminal definition specifies a terminal with ZLU of 120 on Card 1
Port 6.
Chapter 4 37
Protocol Specific Configuration
Non-E1/T1 HDLC.FRAME Configuration Values
Non-E1/T1 HDLC.FRAME C onfiguration
Values
Poll Word
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved (0) AZR AZT 0 CWEN RSIG DSIG RTS Reserved (0)
All reserved bit positions must be filled with zeros (0).
AZR - (Z7340A only) Analyzer terminal for received data
Enables this terminal for monitoring frames received on the port. All
received frames are copied, and the copy delivered to the receiving
application for this terminal. This terminal cannot be used to transmit
frames.
AZT - (Z7340A only) Analyzer terminal for transmitted data
Enables this terminal for monitoring frames transmitted on the port. All
transmitted frames are copied, and the copy delivered to the receiving
application for this terminal. This terminal cannot be used to transmit
frames.
CWEN - Enable the use of formatted Control Write requests
If set to one (1), this bit enables the use of formatted control write
requests. See the “Request Specific Processing” section of Chapter 3 ,
“Using HDLC.FRAME Protocol,” for the format to be used.
RSIG - Report status on CTS or DCD signal state change
If set to one (1), this bit enables an unsolicited status message to be
delivered to the receiving application when either of the CTS or DCD
signals is dropped, and when both CTS and DCD are raised.
If this bit is set to zero (0), the HDLC.FRAME terminal does not report
the state of the CTS and DCD signals.
38 Chapter4
Protocol Specific Configuration
Non-E1/T1 HDLC.FRAME Configuration Values
DSIG - Go down on loss of signal
If set to one (1), this bit will cause the HDLC.FRAME terminal’s status
to be changed to DOWN when theCTS orDCD signalis lost. At thesame
time, an unsolicited status message is delivered to the receiving
application. The RSIG option has no effect in this case.
If this bit is set to zero (0), then the HDLC.FRAME terminal continues to
operate whatever the state of the CTS and DCD signals.
RTS - Control the RTS signal on transmitted frames
If set to one (1), this bit will cause the RTS signalto be raised when the
HDLC.FRAME terminal has a frame totransmit. When CTS is raised by
the remote device, the frame is transmitted after frame transmission
RTS is dropped, unless there is another frame to transmit.
Ifthisbitissettozero(0),thenRTSiskeptraisedaslongasthe
HDLC.FRAME terminal is enabled.
Select Word
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Reserved (0) BADFR Reserved (0)
All reserved bit positions must be filled with zeros (0).
BADFR - Bad frame completion
If set toone (1), this bit causes received frames with bad CRC or received
aborted frames to be passed up to the receiving application with a status
code indicating the error condition.
If this bit is set to zero (0),then all received frames with bad CRC or
received aborted frames are discarded.
Protocol Option Word
The option word is not used with the HDLC.FRAME protocol.
Chapter 4 39
Protocol Specific Configuration
E1/T1 HDLC.FRAME Configuration Values
E1/T1 HDLC.FRAME Configuration Values
Poll Word
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
00AZRAZT000SS7FISUFlags
All reserved bit positions must be filled with zeros (0).
FISU Flags - FISU inter-frame flag count (SS7 only)
Sets the number of flag octets to be inserted between transmitted FISU
frames. The flags reduce the frequency of FISU transmission.
Recommended value - 6.
SS7 - Enable SS7 processing
Enables the automatic handling of transmitted and received FISU and
LSSU frames. Refer to Appendix B, “Using the SS7 Mode Feature,” for
details of the SS7 mode of operation.
AZT - Analyzer terminal for transmitted data
Enables this terminal for monitoring frames transmitted on the
subchannel.
All transmitted frames are copied, and the copy delivered to the
receiving application for this terminal. This terminal cannot be used to
transmit frames.
AZR - Analyzer terminal for received data
Enables this terminal for monitoring frames received on the subchannel.
All received frames are copied, and the copy delivered to the receiving
application for this terminal. This terminal cannot be used to transmit
frames.
40 Chapter4
Protocol Specific Configuration
E1/T1 HDLC.FRAME Configuration Values
Select Word
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Bulk-Rx Discard-rate
Discard-rate - Received FISU or LSSU frames to discard
(SS7 only)
This determines how many FISU or LSSU frames are received and
discarded before one is passed up to the receiving application.
The actual number of frames discarded is obtained by multiplying this
parameter by sixteen (16).
Recommended value - 200.
Bulk-Rx - Received frame group processing (SS7 only)
This parameter sets the number of received frames to be queued up
before processing. Because of the high volume of short received frames
used with the SS7 protocol, it can be beneficial to CPU performance not
to process each of the received frames as it arrives. Only the internal
processing of HDLC.FRAME is affected by this parameter.
Recommended value - 4.
Protocol Option Word
The option word is not used with the HDLC.FRAME protocol.
Predefined Configuration Values
The following parameter can be used in place of the poll and select
parameters to configure an SS7 subchannel with a set of default
parameters:
SS7_OPT - Set up an SS7 frame terminal
An example terminal definition using the SS7_OPT parameter would be:
Term 120 1:6 HDLC.FRAME SS7_OPT 1000 0 0 0 0 "SS7 device port 6"
Chapter 4 41
Protocol Specific Configuration
E1/T1 HDLC.FRAME Configuration Values
42 Chapter4
A Sample Configuration File
43
ttgen
Configuration
system-name "ACC ttgen input file"
Program-Zlu 100
TERMINAL-zlu 1200
LOGICAL-TERM 1000
Physical-Term 1000
BUFFER-POOL 3000000
logical-size 252
Queue-Limit 200
Transmit-Limit 100
Unack-Limit 5000
Port-Limit 20000
E1T1-Port-Limit 100000
node-entry 1
Sample Configuration File
Terminal Definition
Terminal Definition
The file shown is an example of the configuration of HDLC.FRAME
protocol devices.
Interface-Definition
<card-type> 00 0:4 /opt/acc/<card_type>/loopback.zabs
Port-Definition
Port 00:00 RS232 9600 Int SDLC x1 NRZ
Port 00:01 RS232 9600 Ext SDLC x1 NRZ
Port 00:02 RS232 9600 Int SDLC x1 NRZ
Port 00:03 RS232 9600 Ext SDLC x1 NRZ
Port 00:04 RS232 9600 Int SDLC x1 NRZ
Port 00:05 RS232 9600 Ext SDLC x1 NRZ
Port 00:06 RS232 9600 Int SDLC x1 NRZ
Port 00:07 RS232 9600 Ext SDLC x1 NRZ
Terminal-Definition
Term 0001 0:0 HDLC.FRAME 0000h 0000h 10000000”HDLCFrame - Int clock”
Term 0002 0:1 HDLC.FRAME 0000h 0000h 10000000”HDLCFrame - Ext clock”
Node-Definition
Local-Node 123
End$
44 AppendixA
B Using the SS7 Mo de Feature
45
Using the SS7 Mode Feature
Transmitting Frames
Transmitting Frames
When enabled HDLC.FRAME beginssending flags. The application can
then send a MSU, LSSU or FISU to HDLC.FRAME for transmission.
Note that an LSSU may have one or two bytes of status information.
Following the transmission of the frame, HDLC.FRAME enters one of
two states. The two states are the FISU transmission mode or the LSSU
transmission mode and they are set according to the following rules:
• If an MSU or FISU is transmitted first, HDLC.FRAME enters the
FISU transmission mode. In this mode HDLC.FRAME continues to
send FISUs, until the application sends a new frame for
transmission.
• If an LSSU is transmitted first, HDLC .FRAME enters the LSSU
transmission mode. In this mode HDLC.FRAME continues to send
LSSUs, until the application sends a new frame for transmission.
During the ensuing operation, the transmission mode may change as
follows:
• When a FISU is sent by the application for transmission, and
HDLC.FRAME is currently in LSSU transmission mode,
HDLC.FRAME changes to FISU transmission mode.
• When an LSSU is sent by the application for transmission, and
HDLC.FRAME is currently in FISU transmission mode,
HDLC.FRAME changes to LSSU transmission mode.
• When an MSU is sentby the application for transmission, the
HDLC.FRAME transmission mode is unchanged.
46 AppendixB
Using the SS7 Mode Feature
Receiving Frames
Receiving Frames
When enabled HDLC.FRAME begins receiving frames from the line. The
first frame receivedis passedto the application. After the first frame has
been received, the contents of received frames and the current state of
HDLC.FRAME are used to determine whether subsequent frames are
passed to the application.
Whena LSSU frame is receivedHDLC.FRAMEenters “LSSUreceiving
mode”.
When a FISU frame is received HDLC.FRAME enters “FISU receiving
mode”.
When in “FISU receiving mode”:
• AnyFISUwiththesamesequencenumbersasthepreviousframeare
discarded and not passed to the application. However the
“discard-rate” parameter sets a limit for the maximum number of
FISUstobediscarded,withnointerveningMSUorLSSU,andwith
the same sequence numbers. When this limit is reached one FISU is
passed to the application, and the discard count is reset.
• If an LSSUis received, it is passed to the application and
HDLC.FRAME enters “LSSU receiving mode”.
When in “LSSU receiving mode” Any LSSU with the same sequence
numbers as the previous frame and the same status byte(s) as the
previous LSSU arediscarded and notpassed to the application. However,
the “discard-rate” parameteris processed in the same way as for FISUs
in F ISU receiving mode above.
If a FISU is received, it is passed to the layer-2 protocol and
HDLC.FRAME enters “FISU receiving mode”.
All MSU frames are passed to the application regardless of
HDLC.FRAME’s receive mode. The receive mode is unchanged.
LSSU frames may have one or two bytes of status data.
Appendix B 47
Using the SS7 Mode Feature
Receiving Frames
48 AppendixB
Loading...