Professional Documents
Culture Documents
SS7ATM - Product Description COMPAQ 1.0
SS7ATM - Product Description COMPAQ 1.0
SS7ATM - Product Description COMPAQ 1.0
Abstract:
This document describes the functionality that would be implemented in the Version V4.1 of the IN7
product. This document is Compaq Confidential and may be distributed externally under non-disclosure
agreement.
July 7, 2000
__________________________________
Copyright 2000 by Compaq Computer Corporation
All Rights Reserved.
Page 1 of
Printed in France.
The information in this document may not be changed without express written agreement of Compaq
Computer Corporation.
Change History
Revision
V1.0
Date
July 7, 2000
Description
Creation
Page 2 of
1.
Table of contents
1.
TABLE OF CONTENTS.....................................................................................................................................3
2.
INTRODUCTION................................................................................................................................................5
2.1.
3.
4.
EXECUTIVE SUMMARY.................................................................................................................................9
4.1. SS7ATM CONTEXT................................................................................................................................. 9
4.1.1.
The ATM feature into IN7 stack............................................................................................................9
4.1.2.
Metrics for calibrating IN7 SAAL.........................................................................................................9
4.2. PRODUCT COMPONENTS.......................................................................................................................... 9
5.
DETAILED REQUIREMENTS.......................................................................................................................11
5.1. GOAL REQUIREMENTS............................................................................................................................ 11
5.1.1.
Mixed configuration............................................................................................................................11
5.1.2.
Graphical Interface.............................................................................................................................11
5.1.3.
Standard recommendations.................................................................................................................11
5.2. NON-GOAL REQUIREMENTS................................................................................................................... 11
5.2.1.
Postponed requirements.......................................................................................................................11
5.2.2.
Waiting-list requirements.....................................................................................................................11
6.
SOFTWARE CAPABILITIES..........................................................................................................................13
6.1. ATM CONNECTIVITY............................................................................................................................ 14
6.1.1.
Firmware..............................................................................................................................................14
6.1.2.
Handling congestion and recovery in the board................................................................................14
6.1.3.
Board configuration and management...............................................................................................14
6.1.4.
IN7 Trunk and HSSL entities state relations.......................................................................................14
6.2. SAAL IMPLEMENTATION........................................................................................................................ 14
6.3. SAAL LAYER MANAGEMENT INTERFACE (LMI).....................................................................................15
6.3.1.
SAAL Entity Management...................................................................................................................15
6.3.2.
TRUNK Entity Management...............................................................................................................16
6.3.3.
HSSL Entity Management...................................................................................................................17
6.4. CONFIGURING SAAL VIA S7MP SCRIPTS............................................................................................... 18
6.5. IMPACTS ON EXISTING IN7 COMPONENTS............................................................................................... 19
6.5.1.
DNB device driver...............................................................................................................................19
6.5.2.
Management APIs...............................................................................................................................20
6.6. SAAL POSSIBLE EVOLUTION.................................................................................................................. 21
7.
GENERAL REQUIREMENTS........................................................................................................................22
7.1. ENVIRONMENT...................................................................................................................................... 22
7.1.1.
Hardware.............................................................................................................................................22
7.1.2.
Software...............................................................................................................................................22
7.1.3.
Users....................................................................................................................................................22
7.2. PERFORMANCE...................................................................................................................................... 22
7.3. INSTALLATION AND PACKAGING............................................................................................................. 23
7.3.1.
Installation...........................................................................................................................................23
7.3.2.
Packaging............................................................................................................................................23
7.4. LICENSING............................................................................................................................................ 23
7.5. PUBLICATIONS AND TRAINING............................................................................................................... 23
7.5.1.
Publications.........................................................................................................................................23
7.5.2.
Training...............................................................................................................................................23
7.6. INTERNATIONALIZATION........................................................................................................................ 24
7.7. COMPATIBILITY..................................................................................................................................... 24
7.7.1.
Product Compatibility.........................................................................................................................24
Page 3 of
7.7.2.
Standard Conformance........................................................................................................................24
7.8. USABILITY............................................................................................................................................ 24
7.9. RELIABILITY......................................................................................................................................... 24
7.10.
MAINTAINABILITY............................................................................................................................. 24
7.11.
SERVICE AND MAINTENANCE............................................................................................................. 24
7.12.
EVOLVABILITY................................................................................................................................... 25
Page 4 of
2.
Introduction
The information in this document is subject to change without notice and should not be construed as a
commitment by Compaq Computer Corporation or its affiliated companies. Compaq Computer Corporation
assumes no responsibility for any errors that may appear in this document.
The purpose of the Product Specifications Phase is:
To determine which key attributes from the Product Requirements will be implemented in the product. The
Product Requirements represent the complete set of customer needs. The Product Specifications is a detailed
subset of the Product Requirements, based on resources and other constraints.
To translate the selected subset of the Product Requirements into Product Specifications used by engineers,
writers, and other team members during the project.
To describe :
Product deliverables
Capabilities
Features
Functionality
Quality
Performance.
To define minimum ship criteria, product volumes, and any other factors required by the product team.
The Product Specifications document definitively describes in measurable terms the goals, capabilities, and
external characteristics of a software product. It is a commitment by the development team of what it will build.
The Product Specifications document responds to the Product Requirements document. It will:
Revision Control
This document defines the contents of the product. Application of Documentation Control Procedure (TE-PRO0016) is vital for the project; after it has been finalized and approved, the Product Specifications are frozen. All
change must apply the Project Change Control procedure (TE-PRO-0012).
The project team cannot add functionality that was not listed in the Product Specifications.
The project team cannot delete or reduce functionality that has been listed as a goal.
The project team cannot change the category of functionality after the Product Specifications have been frozen
(for example, a goal requirement cannot be reclassified as a non-goal requirement and vice versa).
Page 5 of
The Product Specifications document is the result of the study of the User Requirements detailed in the Product
Requirements document [R1]. Once finalized, the Product Specifications are the main input to update the first
version of Engineering Project Plan document that gathers the deliverables, milestones and costs.
AAL
CBR
CLP
CPCS
E1
GFC
HEC
LMI
NNI
PDH
PTI
SAAL
SAR
SSCF-NNI
SSCOP
T1
UBR
VBR
VCI
VPI
Description
Asynchronous Transfer Mode
A switching and multiplexing technology based on the segmentation of voice, video, and data traffic
into equal length cells which are then interleaved over a physical connection in a time-asynchronous
manner. This contrasts with TDM where different traffic sources are assigned fixed timeslots
ATM Adaptation Layer
Layer within the ATM model that supports Convergence Sublayer (CS) and Segmentation And
Reassembly (SAR) services into/out of ATM cells. Different AALs exist:
AAL0: this layer nullifies AAL. Data to be sent should fit in an ATM 48 bytes cell.
AAL1: supports CBR traffic, such as video
AAL2: supports VBR traffic, such as packetized audio/video
AAL3/4: supports VBR traffic, such as Frame Relay, X25, SMDS. Being replaced by AAL5.
AAL5: leaner version of AAL3/4, supports Frame Relay, X25, IP,
Constant Bit Rate
Cell Loss Priority 1 bit in ATM cell header : if set to 1, indicates that the cell can be discarded in
cased of congestion
Common Part Convergence Sublayer
European Signal Level 1
2.048 Mbps transport rate within the European PDH hierarchy, supporting 32x64 Kbps channels.
Generic Flow Control 4 bits in ATM cell header, mostly used to extend number of VPIs
supported,as its use is not standardized yet.
Header Control Error checksum over the cell header
Layer Management Interface
Network-Node Interface or Network-to-Network Interface
The NNI is better characterized as a switch-to-switch interface. The ATM Forum has defined a
Private-NNI (P-NNI) to connect switches within a single management domain.
Plesiosynchronous Transmission Hierarchy
A public transmission hierarchy based on a non-synchronous alignment of octets at different levels of
multiplexing. PDH is only bit-synchronous . PDH networks are in the process of being replaced with
SDH networks. Examples of PDH transmission rates include E1 and T1.
Payload Type Identifier 3 bits in ATM cell header
Signaling AAL
Defined in Q.2100 series. Contains among others protocols like SAR, CPCS, SSCF-NNI and SSCOP.
Segmentation And Reassembly
Service Specific Coordination Function at NNI (Q.2140)
Service Specific Connection Oriented Protocol (Q.2110)
1.544 Mbps transport rate, supporting 24 channels
Unspecified Bit Rate
Variable Bit Rate
Virtual Channel Identifier 16 bits in ATM cell header
A label used to identify connections between two ATM stations. Together, the VCI and VPI labels
establish an ATM end-station address.
Virtual Path Identifier 8 bits in ATM cell header
Used to identify each VP across the UNI or NNI. The VPI is an 8-bit field at the UNI; 12 bits at the
NNI (no GFC).
Table 1 List of Terms and Acronyms
Page 6 of
3.
All documents are available on IN7 Engineering Site Scape forum (SSF) ) located on
http://teleng.vbe.cpqcorp.net/ under SS7 Engineering/Development Projects.
All the project documents are under SS7ATM SSF.
Note: the Product Specifications of the DNB device driver should be available soon under IN7 Engineering SSF,
but as it is not ready at the time of writing the present document, it is not referenced here below.
Page 7 of
4.
Executive Summary
MTP3 / MTP3-B
Q.704 / Q.2110
SSCF at NNI
Q.2140
SAAL
Q.2100
SSCOP
Q.2110
Physical layer
(PDH 2 Mbit/s link)
G.804
The physical layer will be performed by using the PT-PCI37x-p board from PTI which include the MPC860SAR
processor and provides dual E1/T1 connectivity.
This processor handles AAL5 layer on top of ATM connectivity.
The SAAL layer is a new component to be implemented and that will be fully integrated into the IN7 stack. It will
be implemented as running within the FEP process, but may be eventually embedded in the board later on, in case
of performance problems.
Page 8 of
Page 9 of
5.
Detailed Requirements
VPI and VCI values will be fully configurable via standard IN7 management procedures on new HSSL
entities.
Errors reporting and monitoring will conform to IN7 standard error reporting mechanism.
G.804 compliance is fully performed by the MPC860SAR processor tuning, including:
scrambling
no use of TS0 and TS16 for E1 links (implicit use of G.804)
Maximum supported signaling information size is 272 octets
Possibility to have mixed link sets, i.e. regular 64/56 Kbit/s over E1/T1 or V35 links and ATM over E1/T1
links within a same link set.
IN7 MTP3 will support extended changeover messages (XCO/XCA) and will support an FSN encoded on 3
octets when changeover occurs on a high-speed link. However, the maximum number of messages to be
retransmitted is limited to 128 per link (regular MTP2 requirement).
As this new feature will be fully backward compatible, the management of ATM functionality through GUI
interface will also be supported. In fact, the impact on GUI is not so important, as an SS7 link within GUI will
map either a High-Speed Link or a Regular Link.
CHINA and ANSI recommendations (T1.645 for SSCF-NNI, T1.637 for SSCOP) should be implemented.
full support of Q.2210 recommendations (4 Koctets signaling information size) if needed by upper layers to
MTP3-B
J1 and OC-3 connections
mixed configuration within a same FEP
Page 10 of
Page 11 of
6.
Software Capabilities
The software implementation for handling high-speed signaling links can be depicted as:
MTP3 (+ XCO/XCA)
MTP2_SWITCH
SAAL
SSCF-NNI
LMI
SSCOP
STARLET
device driver
HOST
PCI / cPCI Bus
UpStream / DownStream
Boot
BOARD
Background
AAL5 API
MPC860SAR
Framer E1/T1
Page 12 of
6.1.1. Firmware
In order to send SSCOP messages coming from the host through an ATM link using AAL5 (and vice-versa), a
firmware should be developed based on current firmware architecture for PTI boards. This firmware is made up
from different parts:
programming the E1/T1 framer
an AAL5 API to provide an easy way to transmit/receive frames over ATM network through the processor
serial interface, including:
general MPC860SAR initialization
creation/deletion of an AAL5 channel
transmission/reception of frames over an opened AAL5 channel
issue commands
report events and counters
a bootstrap
downstream and upstream modules for storing messages from/to host
a background scheduler for processing messages from host and from network
The state relations between HSSL and Trunk entities are based on the same model than the one used at MTP2
level for Trunk and Data-Link entities. In ATM case, there is only one HSSL per Trunk, so that a critical problem
occurring on a trunk entails an HSSL going out of service.
Page 13 of
independent thread. Indeed, it could be eventually embedded in the board so that an independent thread will be
quite straightforward to embed.
SSCOP protocol is the main class for handling SAAL traffic over ATM AAL5 connections. In order to provide a
reliable transfer for MTP3 packets, it implements a transmitter and a receiver as specified in Q2110.
SSCF-NNI specifies the interface for using SSCOP. An API at SSCF-NNI level will be developed for MTP3 level
use. This API allows to pass commands from MTP3 to SAAL and to report indications from SAAL to MTP3.
MTP3 (or MTP2_SWITCH, to be defined in design) should be modified in order to use SAAL instead of MTP2 as
a data-link transport layer. Also, MTP3 should handle FSN/BSN encoded on 3 octets for extended changeover
procedures.
MTP2
HSSL
DATA-LINK
SAAL
TRUNK
HSSL
MTP3
TRUNK
SAAL entity is a meta-entity (like MTP2). It cannot be instantiated more than once.
HSSL entity and TRUNK entity (different from the one defined under MTP2) can be instantiated as many highspeed links to be handled. Even non-local high-speed links can be instantiated in SAAL LMI (for LMI redundancy
purpose).
There should be always only one HSSL entity for one TRUNK entity. The TRUNK entity is to be defined before the
definition of an HSSL entity, as there is a reference to an TRUNK into HSSL characteristics.
Note: all timer characteristics will be reported in hundredth of seconds, for IN7 coherence.
Definition
name of the entity
uid of the entity
Syntax
OctetString[8]
OctetString[16]
Settable
no
no
Default value
0
empty
software version
size of SIF used at MTP3 layer
OctetString[4]
uint32
no
no
X400
272
uint32
no
disabled
OctetString
Counter32
no
no
uint32
uint32
Page 14 of
also contains all characteristics to define the ATM protocol running on that link. If, in the future of IN7, SAAL
will run on top of optical fibers, then TRUNK entity will contain extra characteristics to fully define OC links.
Identifiers
NAME
Definition
name of the entity (1..9999999)
Syntax
OctetString[8]
UID
Characteristics
DEVICE_NAME
OctetString[16]
String[6]
uint32
uint32
uint32
uint32
uint32
uint32
uint32
mandatory
at creation
mandatory
at creation
no
at creation
at creation
at creation
at creation
at creation
at creation
uint32
at creation
USE_A
OFF
ESF
B8ZS
56
YA_NOT_TR
SM
2OVER6
uint32
at creation
uint32
at creation
uint32
at creation
uint32
at creation
uint32
at creation
uint32
uint32
at creation
at creation
ON
ITU
uint32
uint32
uint32
at creation
no
at creation
VBR
AAL5
0xFFFFFFFF
uint32
no
disabled
OctetString
Counter32
Counter32
Counter32
Counter32
no
no
no
no
no
Counter32
Counter32
Counter32
Counter32
Counter32
Counter32
Counter32
Counter32
Counter32
Counter32
Counter32
Counter32
no
no
no
no
no
no
no
no
no
no
no
no
Counter32
Counter32
Counter32
no
no
no
FEP_NAME
TRUNK_TYPE
E1_REMOTE_ALARM
E1_CRC4
T1_FRAMING
T1_ENCODING
T1_BANDWIDTH
T1_YELLOW_ALARM
T1_OOF_RATIO
CELL_HEADER_GFC
CELL_HEADER_VPI
CELL_HEADER_VCI
CELL_HEADER_PTI
CELL_HEADER_CLP
ATM_SCRAMBLING
ATM_IDLE_CELLS
ATM_QOS_CLASS
ATM_A_LAYER
ATM_TIMESLOTS
Status
STATE
Counters
CREATION_TIME
FW_TIMEOUT
TKCNT_LOSES
RX_CARRIER_LOSES
RX_SYNCHRO_LOSE
S
AIS_TRANSMITTED
AIS_RECEIVED
ALARM_REMOTE
CODE_VIOLATIONS
CRC_ERRORS
EFS
ES
SES
CSES
CRITICAL_ALARMS
E1_FEBE
SLIPS
HEC_ERRORS
CELLS_TRANSMIT
CELLS_RECEIVED
String
Settable
mandatory
at creation
no
Default value
empty
Page 15 of
Events
TKCNT_LOSES
TKCNT_RECOVERED
CRITICAL_ALARMS
CLEARED_ALARMS
uint32
uint32
uint32
uint32
UID
Characteristics
TRUNK_NAME
FEP_NAME
TB_SIZE
TB_CGT_ONSET
TB_CGT_ABAT
RTB_SIZE
RB_SIZE
K
J
MAX_CC
MAX_PD
MAX_STAT
TIMER_CC
TIMER_KEEPALIVE
TIMER_NORESP
TIMER_POLL
TIMER_IDLE
TIMER_T1
TIMER_T2
TIMER_T3
N1
Status
STATE
SSCF_STATE
SSCOP_STATE
Counters
CREATION_TIME
PDU_TRANSMITTED
PDU_RECEIVED
ALIGNMENT_FAILED
UNSOLICITED_PDU
UNSUCC_RETRANS
LIST_ERRORS
SD_LOSS
CREDIT_CONDITION
DURATION_INS
Definition
name of the entity representing the
PLN used to define an MTP3 link
(1..4096).
Note that this name should be unique
among (HSSL + DATA-LINK) set.
uid of the entity
Syntax
OctetString[8]
Settable
mandatory
at creation
Default value
OctetString[16]
no
empty
OctetString[8]
String
mandatory
at creation
no
uint32
uint32
uint32
uint32
uint32
uint32
at creation
at creation
at creation
no
no
no
128
30
50
128
128
computed
uint32
uint32
uint32
uint32
uint32
uint32
uint32
uint32
uint32
uint32
uint32
uint32
at creation
at creation
at creation
at creation
at creation
at creation
at creation
at creation
at creation
at creation
at creation
at creation
at creation
4
4
500
67
200 ms
100 ms
1500 ms
100 ms
100 ms
5000 ms
30000 ms
computed
1000
uint32
no
disabled
uint32
uint32
no
no
out of service
idle
OctetString
Counter32
no
no
Counter32
Counter32
no
no
Counter32
Counter32
Counter32
Counter32
Counter32
Counter32
no
no
no
no
no
no
Page 16 of
SL_FAILURE_ALL
SL_FAILURE_NORSP
SL_FAILURE_EXCES
SL_FAILURE_CGT
Events
IN_SERVICE
FAILURE
CGT_START
CGT_END
ALIGNMENT_FAILED
TIMEOUT
START_PROVING
STOP_PROVING
PROVING_FAILURE
SSCOP_ERROR
SSCOP_UNITDATA
LP_OUTAGE
LP_RECOVERED
SSCF_REPORT
Counter32
Counter32
Counter32
Counter32
link in service
link failure (any reason)
start of link congestion
end of link congestion
initial alignment failure
timer (any) expired
start of proving period
end of proving period
proving was not successful
SSCOP error report (any reason
cf.Q2110)
SSCOP Unit Data report (cf. Q2110)
start of Local Processor Outage
end of Local Processor Outage
events (any) detected by SSCF (cf.
Q2140)
uint32
uint32
uint32
uint32
uint32
uint32
uint32
uint32
uint32
uint32
no
no
no
no
uint32
uint32
uint32
uint32
HSSL
Qualifiers
/devname
/fepname
/e1remotealarm
/e1crc4
/t1framing
/t1encoding
/t1bandwidth
/t1yellowalarm
/t1oofratio
/gfc
/vpi
/vci
/pti
/clp
/scrambling
/idlecells
/tkcntloses
/tkcntrecovered
/criticalalarms
/clearedalarms
/trunkname
/tbsize
/tbcgtonset
/tbcgtabat
/k
/j
/maxcc
/maxpd
/maxstat
/timercc
/timerkeepalive
/timernoresp
/timerpoll
/timeridle
/timert1
/timert2
/timert3
Shortcut
/d
/f
/e1r
/e1c
/t1f
/t1e
/t1b
/t1y
/t1o
/g
/vp
/vc
/p
/c
/s
/i
/tkcntl
/tkcntr
/cr
/cl
/tr
/tbs
/tbcgto
/tbcgta
/k
/j
/maxc
/maxp
/maxs
/timerc
/timerk
/timern
/timerp
/timeri
/timert1
/timert2
/timert3
Description
Mandatory: physical device and associated port
Mandatory: FEP where link is physically attached
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
event: cf. LMI
event: cf. LMI
event: cf. LMI
event: cf. LMI
Mandatory: name of physical TRUNK
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Optional: cf. LMI
Page 17 of
/n1
/inservice
/failure
/cgtstart
/cgtend
/alignmentfailed
/timeout
/startproving
/stopproving
/provingfailure
/sscoperror
/sscopunitdata
/n
/i
/f
/cgts
/cgte
/a
/timeo
/sta
/sto
/pro
/sscope
/sscopu
In the case of the first implementation of SAAL layer, no new verb will be defined within SAAL.
The device driver should be able to identify new ATM boards. Although PT-PCI37x-p is quite identical to classical
PT-PCI37x board in terms of hardware, a different prefix name will be used for both types of board at management
level (s7mp) in order to differentiate their capabilities. Indeed, at configuration level (ss7configure), board types
should be different in order to download the right firmware to the relevant board. Device driver (and Starlet)
should be modified to handle the new device-id and associated firmware.
DNB tools should also be modified to download ATM specific firmware to relevant boards.
Each framer (attached to a trunk) of the board could be used to handle traffic, so that two trunks can be handled by
a single board. The following naming convention will be used to refer to a PTI ATM board:
pt39xn, where x is the slot where the board is assigned to the rack, and where n is the trunk used (0 or 1).
Note that no divert timeslots facility will be available.
The driver will provide two communication channels for dialog between firmware and hosted SAAL, that is one
for data and the other one for management purpose. In case of board congestion, a kind of priority will be given to
management channel versus data channel.
Only portable API (on all OS) will support the new functionality.
However, non-portable API (VMS case only) will still be compatible with this version of IN7, even if the new
functionality will not be supported for that API.
Page 18 of
SAAL LMI
STARLET
HOST
device driver
BOARD
Background
SAAL
LMI
SSCF-NNI
SSCOP
AAL5 API
MPC860SAR
Framer E1/T1
Note: current experience of PTI boards show that there could be some memory problems when handling new
firmware.
Page 19 of
7.
General Requirements
7.1. Environment
7.1.1. Hardware
ATM connectivity should be fully compatible to both PCI and CompactPCI bus interfaces.
This feature is targeted on Compaq Alpha Servers (PCI and cPCI) and on Proliant Intel (PCI bus on cPCI frame).
Connectivity will support E1 and T1 links.
Hot-swap capability will not be supported in first firmware versions.
7.1.2. Software
High-speed signaling links feature will be fully integrated to IN7 V4.1 (ITU, ANSI and CHINA) and will be
available on following operating systems:
Hardware Platform
Alpha Server PCI bus
Alpha Server cPCI bus
Proliant Intel PCI bus
Intel cPCI rack
Tru64
UNIX
4.0F and +
DIGITAL
OpenVMS
V7.2 and +
Windows
NT 4.0
Windows
2000
7.1.3. Users
N/A
7.2. Performance
New SAAL feature should not consume too much CPU and memory, so that the workload of the hosted SAAL
software is expected to be equivalent of the workload of the hosted MTP2 software for running V35 links, at a
same throughput level. IN7 performances should also be equivalent to standard E1/T1 links in terms of
throughput, either considering board performances (around 850 TPS) than host performances (today more than
2000 TPS per FEP, depending on FEP capacity).
RTT (round-trip time) delay should be equivalent to the one observed for regular IN7 E1/T1 connections for a
same throughput. That is, it should not be more than 80 ms when running a standard TCAP application at 50% of
the overall maximum capacity.
An optional feature for embedding SAAL software in the board should be available, if needed, in future releases of
IN7 high-speed signaling links in order to have an equivalent FEP activity when running classical E1/T1 links, if
and only ATM board supports it in terms of performance as well.
Page 20 of
7.3.2. Packaging
This feature will conform to IN7 packaging strategy.
7.4. Licensing
This feature will be part of general IN7 licensing.
7.5.2. Training
IN7 training courses need to be updated.
7.6. Internationalization
Page 21 of
N/A
7.7. Compatibility
7.7.1. Product Compatibility
This new functionality will be fully compatible to IN7 V4.1 and higher versions. There will be an ascendant
compatibility on existing IN7 software, so that IN7 including SAAL feature should behave exactly the same as it
does today while not using any functionality of this new feature, for example using only DNBC4 or DNBE1
boards.
It should be backward compatible also for MGT API purpose.
7.8. Usability
The strategy for user interfaces in terms of help, training, error reporting will follow IN7 strategy. The IN7 trace
logging facility of the FEP will be used for SAAL software. The IN7 firmware logging facility will also be used
within the firmware.
7.9. Reliability
Firmware errors will be treated the same way as current errors occurring on standard E1/T1 boards.
7.10. Maintainability
This feature will conform to IN7 software product maintainability strategy.
7.12. Evolvability
This new feature will conform to IN7 product strategy.
Page 22 of
Page 23 of