@device(x2700)
@make(report)
@flushleft{EDINBURGH UNIVERSITY COMPUTING SERVICE}
@flushleft{COMMUNICATIONS GROUP}
@blankspace(3 in)
@majorheading{Report on the Responses to

The Operational Requirement for

a Network Level Converter}
@blankspace(2 in)
@heading(April 1988
Release 1 - Draft)
@newpage
@section(Introduction)
This is a report for the JNT on the responses to the 'Operational Requirement 
for A Network Level Converter' dated February 1988.

There were three responses to the OR from Microscope, Netcomm and SEEL and a 
fourth, unofficial response from NET-TEL.

Each  response is examined in detail later in the report with points highlighted
where it fails to meet the requirements of the OR.   A summary of  the
conclusions is given below.

@section(Summary)
@subsection(Microscope)
Microscope have made a very full response to the OR but have proposed a 
standalone box which barely meets the performance requirements and may require a
Network Management Centre to function fully.  A number of other points need 
further clarification.
The cost of the proposal is
extremely high.

@subsection(Netcomm)
Netcomm have proposed a standalone box which offers a considerably higher 
performance than requested.  Some, relatively minor, points still require to be
clarified.  The overall cost is the lowest of the four responses.

@subsection(SEEL)
SEEL have proposed an addition to their existing switches. The response was a 
very poor one which omitted to answer many of the mandatory points.  It does 
offer a novel solution which potentially could provide a high powered converter
but would require substantially more work to validate the method. The cost of 
the additional hardware is still greater than the Netcomm box.

@subsection(NET-TEL)
  NET-TEL  submitted a letter outlining a possible proposal, the basis of which
  was
adding a purely software module into a GEC switch; this proposal requires GEC to
make code available to NET-TEL.   The additional code in
the GEC switch
could  seriously  reduce  the  switch  performance  and  would require all sites
without a GEC switch to purchase one.   These additional purchases would  remove
any price advantage.

@section(Recommendation)
On the basis of the above, the Netcomm proposal is significantly better than 
the rest and negotiations should be held with them to attempt to clarify the 
remaining points.  In the event of this negotiation failing both the Microscope
and SEEL proposals should be followed up.



@newpage
@set(section=0)
@majorheading(Microscope)
@section(Introduction)
Microscope provided a very full, detailed and proficient response to the OR,
covering both technical details and implementation plans.

@section[Overview and Functionality]
Microscope are proposing a standalone unit built upon a structure with a number 
of subsystems each with a Z80 compatible processor and DMA chips.

@section[Operation and Management]
The converter can be managed from a directly connected terminal with 
configurations stored in battery backed RAM of 8 kbytes.

It is not clear which tables operators can modify without taking the converter
out of service.

@section[Protocols]
X.29 is carried using the Q bit over X.25(84); CONS calls are stated as being
carried over X.25(84) rather than ISO 8208/ISO 8878 as in the requirement.

@section[Title-to-Address Mapping]
Support for the NRS, including the use of NLP, is offered but there is no
explicit statement that both Standard and Abbreviated names will be supported.

NRS data will be cached, the cache size is a rather inadequate 10 to 20k bytes
(established by later contact).

@section[Performance and Limitations]
The converter will support two synchronous lines running at a maximum speed of 
64 kb/s.

The converter will support a maximum of 50 simultaneous calls as against a
minimum of 50 required by the OR.

The maximum packet throughput figures are stated, 28 packets/sec at 128 byte 
packets and 48 packets/sec at 16 byte packets.
This packet rate will not give an acceptable performance to a user of an
interactive call when the converter is heavily loaded.

@section[Connection Timeout]
The desirable feature of an inactivity timeout has been included, the timer is
configurable.

@section[X.29 and TS29 calls]
The desirable user interface requirements will be met although Microscope wish 
to discuss the exact requirement.

@section(Synchronous Interfaces)
Microscope are prepared to support a configurable DTE/DCE option  
(for software) although a
system restart would be required. No statement is made of a hardware DTE/DCE 
option.

Microscope will only support V.35 interfaces  which is rather restrictive in 
the current environment.

@section[Network Management - General]
Microscope discuss the management of the converter in a multi-supplier 
environment but it does appear to be restricted to GEC products overall.

@section[Network Configuration Changes]
The network configuration tools appear to be reasonably comprehensive. As noted
above, certain changes do require a system reload and this area would
need further exploration to establish whether any 'critical' features
require a reload.

@section[Management Protocols]
Microscope will use a proprietary protocol for network management. They do make 
the necessary commitments.

A more serious problem is that some of the management functions @b(require) a 
network management station, they are:
@enumerate{
Set Parameters

Reset and/or return accumulated statistics

Teleload  (Converter operational code)

Load address tables  (links & addresses)

Get Diagnostic Status

Set NRS Call Option

Set Inactivity Timeout Option
}
Whilst some of these are not critical, eg, statistics operations, the rest are
and it may be impossible to run a converter without an NMC.

@section(Delivery and Acceptance)
Microscope have stated that the implementation project will take 7 months, thus
the contract would have to be awarded by the 1st June to achieve the timescale
of 1st January.

@section(Maintenance and Support)
Microscope are offering a hardware and software support service.  A 10 year 
period is implied but not directly stated for the hardware.

The options of a fixed contract, Time and Materials and return to factory 
are offered; the terms of
providing circuit diagrams are stated as @b{none} and Microscope would wish to 
discuss third party maintainers further with the JNT.


@section(Procedures and Special Conditions)
@enumerate{
Specification:  H/W and S/W given, no information on CONS

Price per Unit:  @t{#}224,250 for the first
                 @t{#}  7,750 for the next four or more

Total Purchase Price: Not stated but is  @t{#}255,250

H/W Maintenance price: stated:
The terms for an 8 hour callout are @t{#}1134 per annum per converter

S/W support:
The software maintenance is @t{#}4360 per annum per converter

Formula: Reviewed Annually

Warranty Conditions: 90 days

Further Units: Price quoted with complex discount structure
}

@section(Conclusions)
The quality of the Microscope proposal is very high but there are a number of 
problems of which the most serious are:-
@enumerate{
Power:  The number of calls only just fulfils the requirement and the number 
of packets/sec is very low even in relation to the number of calls.

NMC:    The converter appears to require an NMC for some of its management and 
configuration.

Delivery: The probable delivery is after the 1st January 1989

Price: The price is very high
}

@newpage
@set(section=0)
@majorheading(Netcomm)
@section(Introduction)
Netcomm have responded with a fairly short response (6 pages).

@section[Overview and Functionality]
Netcomm are proposing a standalone unit built upon a
Motorola MC68010 chip and Hitachi HD64180R1P8 chips to handle the synchronous 
links.

@section[Operation and Management]
The converter can be managed from a directly connected terminal,
an X.29 call from the network or via a network management protocol with
configurations stored in non-volatile memory.

It is stated that modifications can be made to name and address tables without 
taking the converter out of service.

@section[Protocols]
Conversion of protocols will be carried out as specified in the OR.  The CONS 
interface will not support Receipt Confirmation; expedited data selection will
be as required for the YB mapping and Q of S will be supported if the converter
is supplied with the relevant information.

@section[Title-to-Address Mapping]
The proposal offers support for short and long form names; the support of the 
NLP includes a cache of between 256k and 512k bytes.

The call to the NLP can be configurable as either permanent or single shot.

@section[Performance and Limitations]
The converter will support two synchronous lines running at a maximum speed of
500k bits/sec.

The converter will support a maximum of 250 simultaneous calls as against a
minimum of 50 required by the OR.

The maximum packet throughput figures are stated as 200 packets/sec. It is also
stated that the use of DMA copies removes any dependence on packet size.

@section[Connection Timeout]
The desirable feature of an inactivity timeout has been included, the timer is
configurable.

@section[X.29 and TS29 calls]
Support for conversion are as stated in the Transition Report and the 
desirable feature of the use of Annex B of the Green Book will be supported.

@section(Synchronous Interfaces)
Netcomm do not state whether the link interfaces will support both DTE and DCE
on either hardware or software interfaces.

Netcomm will support X.21, X.21 bis (V.28) and a fibre optic interface module. 
It should be noted that V.35 is not supported but this is not a mandatory 
requirement.

@section[Network Management - General]
Netcomm are offering to provide a network management system that will support 
their own products which could be extended to other non Netcomm devices.

@section[Network Configuration Changes]
Netcomm claim that reconfiguration can be achieved without a system reload.

The Netcomm converter can be utilised without the requirement of a network 
management machine.

@section[Management Protocols]
Netcomm use a proprietary protocol for network management. They do make
the necessary commitments.

@section(Delivery and Acceptance)
Netcomm state that delivery will be by the 1st January 1989 provided that the 
contract is placed before the 1st July 1988 and that testing facilities, such
as access to an NLP server and an implementation of Blue Book over CONS, will
also be available in that timescale.

@section(Maintenance and Support)
Netcomm are offering a hardware and software support service.  A 10 year
period is offered.

The hardware support offered is that of a return to factory of either complete 
units or individual boards on either a contract basis or on an individual cost 
basis.  Netcomm do not offer an on-site service.

Details for a site to do their own maintenance is stated.

@section(Procedures and Special Conditions)
@enumerate{
Specification:  H/W, S/W and CONS interface details given.

Price per Unit: @t{#}16,905 for the first five units

Total Purchase Price: @t{#}84,525

H/W Maintenance price: stated:
5% or 6% for return of boards for a 10 or 5 day turnaround, 1st year is 0% or 
1% for the 10 or 5 day service.

S/W support:
The software maintenance is 5% per annum per converter

Formula: Not stated

Warranty Conditions: 90 days

Further Units: Price quoted of @t{#}4,427.50 discounted to @t{#}4,312.50 for 5 or more.
}

@section(Conclusions)
Netcomm have answered virtually all of the mandatory points of the proposal and
have offered a converter with a very high capability and throughput.  There 
does not seem any reason to doubt them on the basis both of the hardware
offered and their track record on PADs.

@newpage


@set(section=0)
@majorheading(SEEL)
@section(Introduction)
SEEL have responded to the OR with an extremely short proposal.

@section[Overview and Functionality]
SEEL are proposing an additional piece of hardware, a Tandon PC with an EICON 
intelligent link card,
to attach
to their switch.  This PC could only be used in conjunction with a SEEL switch 
which would need to be purchased by any University which required a converter 
and did not already own a TelePAC.

@section[Operation and Management]
The PC can be configured either by a local console or via an X.29 call across
the network.

Storage of configurations would be on the PC hard disk.

No statement is made as to whether a reload would be necessary after
reconfiguration.

@section[Protocols]
No precise statement is made about the conversions offered.


@section[Title-to-Address Mapping]
No statement is made about the support of NRS style names.
 The proposal states that the NLP will be supported but no detail is given on 
 the mechanisms.

A cache will be supported and a size of approximately 1 Mbyte was quoted in 
later correspondence.

@section[Performance and Limitations]
The form of the connection between the PC and the TelePAC is a synchronous line
running at speeds of up to 128 kb/s.

The converter is proposed to operate by handling only the call connect packets,
once the call is established call rerouting will take effect inside the switch 
and all data packets go through the switch, not the PC.  This could be done for
YB/CONS calls though it will be significantly harder for TS29/X.29 calls.
  Thus it is claimed
that the 'converter' will support the full switch throughput of 500 data 
packets/sec and 1000 simultaneous calls.  However, no statement is made as to 
the packet or call rate capability of the PC itself.

@section[Connection Timeout]
No statement has been made on the desirable feature of an inactivity timeout.

@section[X.29 and TS29 calls]
Recognition is made of some of the requirements of converting X.29 and TS29
calls though not in enough detail to establish whether the specification is
met.

No statement is made on the user interface requirements in the PC.

@section(Synchronous Interfaces)
As the proposed solution is part of a switch this section does not apply.

@section[Network Management - General]
No statements are made about network management strategies or protocols 
although SEEL have agreed to the conditions in the past when approval was first
granted for switches.  In general configuration is achieved by a simple X.29 
call and the indications are that this strategy would be followed for this
proposal.

@section[Network Configuration Changes]
No statement is made as to whether reloads will be necessary after
reconfiguration.

@section[Management Protocols]
See the section above.

@section(Delivery and Acceptance)
No timescales are given.

@section(Maintenance and Support)
It is claimed that the requirements for maintenance and support will be met 
without any specific details.

@section(Procedures and Special Conditions)
@enumerate{
Specification:  Inadequate H/W, S/W and CONS interface details given.

Price per Unit: Not stated

Total Purchase Price: @t{#}86,250

H/W Maintenance price: Not stated:

S/W support: Not stated

Formula: Not stated

Warranty Conditions: Not stated

Further Units: Price quoted of @t{#}6,325.  No bulk discounts stated.
}

@section(Conclusions)
The SEEL proposal is a novel way of addressing the converter.  It is neither a 
switch software module nor a standalone unit.  Unfortunately there is not 
enough detail to validate the method and the requirement of additional hardware
removes the otherwise considerable benefit of purchasing software.

@newpage

@set(section=0)
@majorheading(NET-TEL)
@section(Introduction)
NET-TEL have sent a letter detailing how they could address a converter if 
requested.  They have not produced an official response as GEC had decided to
respond via Microscope. They are being included here for completeness.

@section[Overview and Functionality]
NET-TEL are proposing to build the converter into existing GEC switch products
which must be running Type 3 software and have sufficient store.

This would mean that sites without a GEC switch would require to purchase one.

@section[Operation and Management]
No statement made.

@section[Protocols]
No precise statement is made about the conversions offered.


@section[Title-to-Address Mapping]
No statement is made about the support of NRS style names.
 The proposal states that the NLP will be supported with either a single shot 
 or permanent call being configurable.

A cache will be supported.

@section[Performance and Limitations]
As the converter is part of the switch, the performance is limited by that of
the switch.

Using figures based on the existing PSE gateway, a figure of 25 data
packets/sec is quoted for a 4160 and 200 data packets/sec for a 4190.

A maximum of 80 simultaneous calls would be supported though on a 4160 a more 
realistic figure would be less than 25.

@section[Connection Timeout]
The desirable feature of an inactivity timeout will be provided.

@section[X.29 and TS29 calls]
No details quoted.

@section(Synchronous Interfaces)
As the proposed solution is part of a switch this section does not apply.

@section[Network Management - General]
Extensions to the existing GEC switch management would be added.

@section[Network Configuration Changes]
No statement is made as to whether reloads will be necessary after
reconfiguration.

@section[Management Protocols]
As per the GEC switch.

@section(Delivery and Acceptance)
A development period of 39 weeks would be required.

@section(Maintenance and Support)
It is claimed that the requirements for maintenance and support will be met 
without any specific details.

@section(Procedures and Special Conditions)
@enumerate{
Specification:  Inadequate H/W, S/W and CONS interface details given.

Price per Unit: Not applicable.

Total Purchase Price: @t{#}132,250 approximately

H/W Maintenance price: Not stated:

S/W support: Not stated

Formula: Not stated

Warranty Conditions: Not stated

Further Units: No cost if a suitable GEC switch exists.
}

@section(Conclusions)
The NET-TEL 'proposal' hinges on GEC giving permission to use and modify their 
code, this agreement has not been reached.

There are two other, major, problems with the proposal. Firstly, if the 
converter is used very heavily, the switch performance would be dramatically 
reduced.  Secondly, any site without a GEC switch, would need to purchase one 
at a minimum of @t{#}25,000.  This requirement reverses the apparent cost
advantages of this
proposal.