@make[report] @device[x2700] @majorheading[X25 Campus Packet Switching Exchange (CPSE) Specification] @section[Functional Modules] A PSE can be considered as a number of functional modules which can be grouped to fulfil a particular requirement. These modules are:- @begin[enumerate] A virtual Call Packet Switch; Access Units - to connect to X25 DTEs and DCEs; Inter-Network Connections - to other X25 networks; Network Management function. @end[enumerate] Each of the above-mentioned functions should be autonomous with well-defined interfaces between them. @subsection[Virtual Call Packet Switch] The PSE will act as a multiple-call Data Circuit Terminating Equipment (DCE) to packet-mode terminals and it will offer virtual call switching facilities over interfaces conforming to Part III of the BT Technical Guide to PSS (reference 1). In particular the following X25 facilities are mandatory:- @begin[enumerate] Fast Select; Packet and Window size negotiations; Call Statistics @end[enumerate] The following X25 facilities are desirable:- @begin[enumerate] Permanent Virtual Circuits; Call Redirection; Reverse charging. @end[enumerate] @subsection[Access Units for Packet-Mode Devices] Each access unit on a PSE must provide a transmission system for the input and output of data bits on the X25 link together with a link access procedure which transmits and receives blocks of data (packets) with some form of error correction. The following bit rates must be supported:- 2.4K, 4.8K, 9.6K, 19.2K, 48K. @newpage Higher speeds are desirable. It is desirable for the access unit to provide clocking signals at all speeds to obviate the need for external equipment purely for this purpose. The physical level must offer V24/V28 and V35 interfaces. X21 interfaces are desirable. The HDLC link access procedure LAPB must conform to Part II of the BT Technical Guide to PSS. It is desirable that the access unit can be configured either as DTE or DCE. It must be possible for a group of links on a PSE, connected to the same DTE, to have the same X25 address. When a multi-link connection is configured the PSE must decide on which link to use for a new call to the DTE based on the current availability and loading of the links. The algorithm should take into account both the number, and the nature, of calls in progress, eg. packet and window size or traffic level. Up to ten links should be able to share a common address. @subsection[Inter-Network Connections] Modules will be required to allow inter-network connections. The type of facilities needed at the inter-network point will to some extend depend on a site's requirements. The PSE will form part of an X25 network. A PSE connected to another network will appear to that network as a multiple call DTE using an X25 connection. There are two options for the inter-network connections:- @begin[verbatim] a) A gateway implementation of the Network Independent Transport Service defined by BT PSS User Forum Study Group 3 ("Yellow Book"), (reference 2). In this case the two networks will have separate X25 addressing domains. b) It must be possible for an access unit on a link to support multiple DTE addresses at level 3 where the multiple addresses may be individual addresses, a range of contiguous addresses, or any combination of single addresses and ranges. @end[verbatim] Once interconnected virtual circuits on each side have been set up the inter-network connection must be transparent. For option (a) the following facilities are required:- @begin[itemize] The gateway must support the use of the X25 Fast Select facility as specified by the minimum recommendations of the JNT (see Annex1). For terminal connection using X29 or TS29 the gateway must provide conversations for TS29 to X29, X29 to TS29 and X29 to X29 conversion in both directions in accordance with recommendations of Study group 3 of the PSS User Forum in the Green Book. Mapping between titles as described in the Yellow Book (2), and addresses must be provided for TS calls via the gateway and associated converters. For X29 calls to the gateway, conversion of names conforming to the JNT Name Registration Scheme (reference 3) to the appropriate TS strings must be provided. A welcome message must be displayed when an X29 call is made to the gateway. The gateway must be able to perform packet and window size negotiation so that connections can always be made between hosts irrespective of whether the destination host can support the values of the parameters initially requested by the source host. It is desirable that this facility can be met by matching different values for the packet and window size on either side of the gateway. Access to other networks via a YBTS gateway requires additional accounting and authorisation facilities, especially for calls to the public network. It must be possible to authorise outgoing calls on a per user basis and maintain a budget for each user. PSS accounting on a per user basis (DTE or NUI if recognised PAD user) must be available. Logging information for calls via the gateway must include details of the local DTE address and the remote DTE address. @end[itemize] @subsection[Network Management] Modules must be provided to collect data on each call, monitor the performance of the PSE, allow operator control of the communications system and warn of fault conditions. The ability to collect management information over a prolonged period by storing it on local backing store must be available. It must be possible to manage one or more PSEs from a designated management centre. The subset of the management functions described below must be available in each exchange and must be accessible from an operator's console attached to that exchange, this method of access being the default when the management centre is not available. The sophistication of the overall functions must be commensurate with the complexity of the network topography that is possible, the number of connected devices, total traffic volumes and the need for charging. It must also be possible to execute the appropriate network management functions in a host computer attached to the network, using the network protocols supported by the PSE. The protocol specifications must therefore be stable and be available in the public domain, and there must be no restrictions on their use in other equipment which forms part of the network supported by the PSE. @paragraph[Statistics] Statistical information collected for each X25 link must include counts of packet types and details of calls in progress. The following packet types should be recorded:- @begin[verbatim] Call Request Incoming Call Clear Interrupt Reset Data CRC errors @end[verbatim] The counts must be cumulative over a defined time interval and it must be possible to alter the time interval, reset to zero, disable the count and trigger alarms when thresholds have been exceeded. Traffic statistics must be provided for each link which allow the percentage utilisation of the available bandwidth of a link to be determined over a selected period. It must be possible to display statistics on a local console. It must be possible to store statistical information on backing store over prolonged periods, and to collect this information at the network management centre for analysis. @paragraph[Status Monitoring] The status of all links must be monitored and it must also be possible to display this information on request either for one, several or all links. The X25 level 3 status information provided must include the total number of calls in existence at any time and the DTE addresses at each end of the calls. It must be possible to list all calls to/from a particular DTE address. Status changes, including alarm conditions, must be recorded in a time-stamped event log. It must be possible to maintain the event log on backing store over a prolonged period and transfer this information to a management centre over the network, on request. It must also be possible to record status changes on a local console as they occur. @paragraph[Control] It must be possible for an operator to:- @begin[itemize] enable/disable any link. test the status of a link. clear a call to a selected DTE address. change network addresses. change line speeds. @end[itemize] It must be possible to perform control and diagnostic functions during normal operation of the exchange. All control functions must be available from a local console and via authorised remote access (eg. from management centre). @paragraph[Gateways] For gateways, the ability to modify the list of authorised users is required. @paragraph[Date-Time Stamp] A date-time stamp must be provided with each unsolicited message appearing on the console. Commands to change and interrogate the date-time must also be provided. It is desirable that the PSE should recover the date and time automatically when a reload occurs after a system failure. @subsection[Multinode Networks] The PSE must be able to operate as part of a multinode network. There must be no differences in the facilities available from the network when making a call involving multiple exchanges as compared to those available when making a call local to one exchange. Multinode configurations should be capable of supporting adaptive routing of calls when the preferred route is not available but an alternative is. @subsection[PSS-Compatibility] The supplier must be committed to maintaining compatibility between his equipment and that currently supported on PSS. This compatibility applies to both hardware and software interfaces. @section[Performance] @subsection[Packet Transmission] The time taken to complete a call attempt is defined as the interval between the receipt by the PSE of the last bit of the @b[CALL REQUEST] packet from a packet-mode device and the onward transmission of the first bit of the resultant packet by the PSE. This interval must be less than 50ms (in the absence of queuing delays) including the time taken to record charging and statistical information. For all subsequent packets in a call, the first bit must be transmitted by the PSE within 10 ms (in the absence of queuing delays) of the receipt of the last bit. On the receipt of a @B[CLEAR REQUEST] or a @b[CLEAR CONFIRMATION] packet from a DTE or a gateway the interval between the receipt of the last bit and the transmission of the first bit of the resultant packet must not exceed 50ms (in the absence of queuing delays) including the time taken to update charging and statistical records. @subheading[Throughput] Typical configuration for PSEs in terms of numbers of lines and throughput are given below. These configurations are given for guidance, rather than as "standard" configurations. The throughput figures below assume a maximum packet size of 128 bytes with an average fill of 100 bytes per packet. @begin[verbatim] @subheading[Configuration A] PSE with 18 X25 connections - 2 x 48 kbps, 16 x 9.6 kbps, including 1 inter-network connection. @end[verbatim] @subheading[Minimum Performance] @begin[verbatim] 200 packets/second peak. 150 packets/second mean. 200 simultaneous calls. Peak = no Network management activity. no Gateway activity. no calls created or cleared. Mean = 5 calls/second created and cleared. Packets are all packets - data and acknowledgements. @end[verbatim] @subheading[Configuration B] @begin[verbatim] PSE with 48 X25 connections - 4 x 48kbps, 44 x 9.6 kbps, including 2 inter-network connections. @end[verbatim] @subheading[Minimum Performance] @begin[verbatim] 700 packets/second peak. 600 packets/second mean. 600 simultaneous calls. Peak and mean as defined in configuration A. @end[verbatim] @subheading[Availability and reliability] Faulty modules must cause minimum disruption to the operation of serviceable modules in the configuration. No more than 0.01% of valid call requests must result in a call not being established to a connected and operational DTE. No more than 1 in 10@+[9] of the valid packets received by the PSE must fail to be transmitted onwards. There must not be a complete failure of the PSE, ie. such that all calls and packets are lost, more than once in every 2000 hours of operation, on average. If the transient overload occurs, eg. buffer exhaustion, a degradation of service to all connected users is allowed while the overload condition persists. Recovery procedures which ensure a complete return to normal working must be initiated automatically. Traffic overload must never result in disconnection of users or system failures. @section[Operation] It must be possible to run the equipment without operator intervention unless there is a complete failure of the PSE. The restart procedures in the event of failures must be extremely simple. Automatic restart in case of power failure or irrecoverable software failure must be available. It must be possible to load the PSE software from a local IPL device. Where backing store is available, automatic dumping of memory and system restart must be performed when inconsistent situations are encountered. @section[Systems Reconfiguration and Enhancement] The equipment will be used in a large variety of configurations with different types of connected equipment, degrees of connectivity and throughput requirements. Tools muat be provided for the flexible configuration of new systems and for the simple field enhancement of existing systems. Customer input to such system configuration facilities must include a definition of the configuration and a list of the functions to be performed. @section[Documentation] For a given configuration, full documentation, including configuration details, annuals, operating instructions and test procedures must be provided. @section[Environment] All the equipment must be capable of working in a normal environment with no special precautions for controlling temperature, humidity or dust. The equipment must operate from the standard domestic power supply (240v, 50 Hz) and must tolerate the expected fluctuations. No stand-by power supplies will be provided in the event of mains failure. Full BT approval for the connection of the PSE to appropriate BT services must be available. Where a YBTS gateway is provided, permission to connect to PSS must be available. @section[References] @begin[enumerate] British Telecom Technical User Guide 17, (June 1983). A Network Independent Transport Service; SG3/CP(80)2, Study Group 3 of British Telecom PSS User Forum, (February 1980). JNT Name Registration Scheme Technical Guide, (April 1983). @end[enumerate] @newpage @flushright[ANNEX 1.] @subheading[JNT Transport Service Recommendations] The @b["Yellow Book"] definition of the Transport Service over X25 offers a number of alternative options for the implementor. In the interests of ensuring simplicity and high interconnectivity, the JNT is recommending a subset of facilities which should be available on @u[all] machines. Many machines will offer a range of facilities over and above those listed here. Knowledge of the full range of methods available in the protocol definition is assumed. @subheading[The Minimum Set of Facilities] @begin[enumerate] The "Fast Select" for on the @b[CALL REQUEST] packet is used so that 124 octets in the call User Data Field are available for the @b[CONNECT] parameters. The @b[CONNECT] parameter information may extend into the following data packet(s). The @b[Address] and @b[Quality of Service] parameters must always be wholly contained in the @b[CALL REQUEST] packet and must not extend into the following data packet(s). Each parameter may be contained within multiple fragments. There should be no user data following the CONNECT parameters in the Call User Data Field. The explanatory text parameter should be truly optional. The receiver should not require the sender to supply this parameter and the receiver should be free to ignore it. As implied in the @b[Yellow Book], the @b[Fast Select] form of the X25 @b[CALL ACCEPT] and @b[CALL CLEAR] packets with the extended User Data field should @u[not] be used. @end[enumerate] @subheading[Interworking with Fuller Implementations] Full implementations of the @b[CONNECT] primitive should be able to interwork with systems which only implement the subset described above. In particular, they should be able:- @begin[itemize] to accept incoming @b[CONNECT] requests limited to the above. to generate @b[CONNECT] requests limited as described above, either in the initial @b[CONNECT] attempt or as a second attempt after a failure indication produced in response to an initial, different style of @b[CONNECT].