@device[x2700]
@make[report]
@blankspace(4 in)
@majorheading{Operational Requirement for


a Network Level Converter}
@blankspace(2 in)
@heading(February 1988
Release 2)
@newpage
@section(Introduction)

The Computer Board, via the Joint Network Team, proposes to fund the purchase
of a number of Network Level Converters
for installation at different UK Academic Community sites.
  The procurement of this
equipment is being carried out by the University of Edinburgh Computing
Service acting
as agents of the JNT.  Any eventual contracts for the supply of equipment to
meet this Operational Requirement (OR) will be between the suppliers and the
University of Edinburgh.

Where the words 'shall', 'will', 'must', 'required' or 'mandatory' are used the
requirements are mandatory.  Where the words 'should' or 'desirable' are used
the requirements are desirable.

Suppliers must make a point by point response to the mandatory and desirable
requirements outlined in the OR.  Suppliers must make clear which facilities,
if any described in their tender will not be available by the quoted delivery
date.

@section(Equipment Required)
The items required are:-
@verbatim[
    5  Network Converters
]

Suppliers must quote terms under which further Converters could be purchased
using Computer Board funds or other funds.
Details of any bulk discounts available to individual sites must also be given.
Further details are to be found in Section 7.

If a manufacturer wishes to supply equipment as an additional item to existing
approved products then the additional cost and any performance consequences must be
clearly stated.

@section[The Converter]
@subsection[Overview and Functionality]

The purpose of a Converter is to map and convert  'The Yellow Book - a
Network Independent Transport Service' running over X.25 (1980) into the OSI
Connection-Mode Network Service and the converse. 
 The need for such a Converter,
including many of its basic functions, are described in the 'Transition to OSI
Standards' report (Reference 1).

The Converter must be in one of the following configurations:-
@itemise{
A standalone unit.

Additional hardware or software for an existing approved product.

An element of an application level converter.
}

@subsection[Operation and Management]
Facilities for configuring the Converter must be provided, 
including the setting up
of name and address tables.  Acceptable mechanisms include the use of
asynchronous lines - manually via a terminal connected directly to the
Converter or via an X.29 call
through the network, local configuration software stored in ROM, and downline
loading over the network.
  It must be possible to store a new configuration in non-volatile
memory. Provision must be made for an operator
to modify address tables without taking the Converter out of service.

@subsection[Protocols]

The protocols to be converted,
X.29, TS29 on the Yellow Book Service and other protocols over the Yellow Book
Service are carried by X.25(1980) (Reference 6) on one side. 
 The X.25(1984) (IS 8208) protocol will
carry X.29 directly using the Q bit. The 'other protocols' will be carried by
the OSI Connection-Mode Network Service
as defined in ISO 8878 (Reference 3) and
ISO 8208 (X.25(1984), Reference 2) on the other side.

The requirements for X.25 (1984) are defined in OSI Requirements Note 1 (ORN 1
- Reference 9).

The description of how to map Yellow Book to the OSI Connection-Mode Network
Service are contained in OSI Requirements Note 3 (ORN 3 - Reference 10).

@subsection[Title-to-Address Mapping]
It is mandatory that support is provided for application titles conforming to
the specifications of the JNT Name Registration Scheme (NRS), reference 7,
including support for both standard ('long') and abbreviated ('short') names of
an entity.  If this
facility cannot be provided on delivery then a commitment to its availability
within defined and reasonable timescales must be given.

The Converter must support the NRS remote procedure call
protocol (reference 8) to obtain the addressing information corresponding to
an application title or ISO NSAP and for ISO NSAP validation; for more details 
see the OSI Transition Report, Section 6.2.
It is desirable that the Converter provides a
caching mechanism to retain the most frequently used application titles in
order to reduce name server interactions.

It is desirable that a choice can be made between whether to hold a permanent
call open to the name server or to make a call for each interaction
as part of the configuration options.

@subsection[Performance and Limitations]

The Converter must be capable of driving at least two synchronous lines at a
minimum speed of 48kb/s, with a minimum of 50 simultaneous virtual calls.

The supplier must indicate the values of the following system limits 
which
apply to the proposed system:
@itemise[
Maximum number of simultaneous calls

Guaranteed data and packet throughput for a range
of packet sizes and numbers of simultaneous calls.

Maximum number of synchronous links supported and any constraints on
which protocol set may run on each link.
]

Any other system limits and configuration details related to such limits 
must also be specified.

@subsection[Connection Timeout]
It is desirable to be able to timeout connections, clearing them after a period
during which no activity has occurred.  If provided, this feature and its
associated timer values must be a configuration option.

@subsection[X.29 and TS29 calls]
The procedures for handling incoming X.29(1980), TS29 and X.29(1984) calls are 
described in detail in Section 7.1.6 of the OSI Transition report.

It is desirable that the user interface for incoming XXX calls, requiring 
additional addressing information,
is in line with the recommendations for
private PAD implementors given in Annex B of the 'Green Book' (reference 3).
In particular, the Terminal-PAD recommendations in section B.6 must be
followed.

@subsection(Synchronous Interfaces)
Suppliers must indicate both the speed and the nature, including DTE/DCE
options, of the
interfaces (eg V24/V28, V35, X21 etc) available for the X.25 connections in
detail.

@section[Network Management]
@subsection[General]
Suppliers must specify how their equipment would be managed in a multi-supplier
situation in order to provide a unified management environment.

@subsection[Network Configuration Changes]
It must be recognised that network equipment is likely to undergo frequent 
reconfiguration.
Whatever mechanism is adopted by implementors
of the network software on attached equipment it must be able to cope with
network reconfiguration without necessitating a system reload in order for the
changes to take effect.

@subsection[Management Protocols]
Any interim management protocols which are used by the Converter
must be based on non-proprietary standards which are in the public domain.
Alternatively, the supplier must make two committments: to place the protocols
used in the public domain before the equipment is delivered; and not to modify
these protocols subsequently without the agreement of the JNT.

@section(Delivery and Acceptance)

The JNT has nominated the University of Edinburgh to conduct acceptance tests and
evaluate the equipment.

All equipment must be delivered to the University of Edinburgh
no later than 1 January 1989. A commitment to an earlier delivery
date will be taken into account when evaluating tenders.

The first item of equipment of each type will be subjected to a preliminary
acceptance test consisting of:
@itemise{
   a functional check that all specified facilities work correctly;

	a check on the device's performance insofar as this is possible using the
	service facilities of the University of Edinburgh;

a check on the quality of the documentation

	a four week period of normal usage at the University of
	Edinburgh.
}
Preliminary acceptance of subsequent items of each type will consist only of
the functional check on facilities at the University of Edinburgh.  Following
preliminary acceptance, equipment will be shipped (at the University of
Edinburgh's risk and expense) to other academic community sites designated by the
JNT.  Final acceptance of the equipment will consist of a four week period of
normal usage at the destination site.  Full details of the acceptance test
procedures will be agreed with the selected supplier(s) prior to delivery of
the equipment.


@section(Maintenance and Support)

Suppliers must offer a hardware and software support service for all equipment
offered.

Each site receiving one or more of the Converters which are the
subject of this OR must have the option of taking out a maintenance contract
under which the supplier repairs any hardware fault that might arise in return
for a fixed monthly maintenance charge.  Suppliers must guarantee to provide
this maintenance service, to those academic community sites which select this
option, for a period of ten years from acceptance of the equipment.  It is
desirable that suppliers also offer the option of hardware maintenance on a
time and materials basis; such a service must also be guaranteed for a period
of ten years from acceptance of the equipment.  Suppliers must also state the
terms on which they would make available the necessary documentation, circuit
diagrams, training and spare parts so that sites could elect to have the
equipment maintained by their own staff or by independent maintenance
contractors.  Suppliers should also offer a hardware maintenance service based
on a return to factory of faulty components.  The maximum delay between
recovering a faulty module and delivering a replacement must be quoted.

A software support contract must also be offered under which software faults
are reported, fixes are provided for all but the most trivial of faults, and
customers are supplied with new releases of software.  Suppliers must specify
the proposed terms of their software support contract.

The supplier must confirm that all maintenance and support services apply to
all parts of the UK.

@section(Procedures and Special Conditions)

Tenders are invited for the supply of the equipment listed in section 2.
Tenders
must contain all the information necessary to evaluate the proposals fully.
They must include in particular:
@enumerate{
a hardware and software specification of the equipment offered, in
 particular the details of the CONS interface  must be given;

the price per unit of equipment offered;

the total purchase price for the complete set of equipment offered;

the cost per unit of each of the hardware maintenance options offered in
 response to section 6 of this OR;

the cost per unit of the software support service offered in response to
 section 6 of this OR;

the formula to be used for varying the cost of hardware and software
 support services during the lifetime of the equipment, and

a specification of the warranty conditions associated with the proposed
	equipment and confirmation that the delivery and acceptance procedures
 outlined in section 5 above are acceptable.
}
Suppliers are also invited to quote prices for further units of equipment
purchased by UK academic community sites.  The detailed form of these
supplementary offers is left open but might include quantity discounts based on
the total number of academic community orders received within twelve months or
conditions such as the use of a single agent site for handling all order and
invoice administration.  However purchases directly by individual sites must be
an option that is quoted.

All prices quoted must include VAT at the current rate.  Prices for the
equipment listed in section 2 must be fixed and must cover all costs of
delivery to the University of Edinburgh and acceptance procedures.

@section(Evaluation Criteria)

Equipment which does not meet all mandatory requirements specified in this OR
will not be considered.  Proposals for each type of equipment outlined in
section 2 will be considered separately.  The extent to which desirable
requirements are met will be taken into account.  Any prices quoted for
subsequent orders placed directly by academic community sites will be taken
into account but with a lower priority than the other criteria.

The final choice nevertheless remains with the JNT and the University of Edinburgh
who shall not be obliged to disclose the reasons for their choice nor to accept
the lowest or any tender.

@section(Tenders and Further Information)

Tenders must be submitted by 1st April 1988 to:
@verbatim{
Dr L Clyne,   3 copies                    Mr B A C Gilmore,   3 copies
Joint Network Team                        Computing Services
c/o Rutherford Appleton Laboratory        University of Edinburgh
Chilton                                   J C M B
Didcot                                    Mayfield Road
Oxon   OX11 OQX                           Edinburgh   EH9 3JZ
}
For further detailed technical information please contact Mr B A C Gilmore
(Tel: 031- 667 1081 ext 2927).  For general technical information and other
matters please contact Dr L Clyne (Tel: 0235- 44 6459).

@section('References)
@enumerate{

Transition to OSI Standards, JNT, July 1987

ISO 8208 Information Processing Systems - X.25 Packet Level Protocol
for Data Terminal Equipment

(Green Book) "Character Terminal Protocols on PSS", SG3/CP (81)/6, February
 1981.

ISO 8878 Information Processing Systems - Data Communications - Use of X.25 to 
Provide the OSI Connection-Oriented Network Service.

ISO 8348/AD2 "Addendum to the Network Service Definition Covering
 Network Layer Addressing"

British Telecom Technical User Guide 17, February 1984.

JNT Name Registration Scheme, Technical Guide, JNT, April 1983.

Name Registration Scheme Lookup Protocol - NRS/9.

UK Academic Community OSI Requirements Note 1  "X.25 (1984) Level 3", JNT
86-10-2

UK Academic Community OSI Requirements Note 3  "Mapping the Yellow Book to the 
OSI Network Service", JNT, 87-2-25
}