@style[spacing=1] @make[article] @device[x2700] @majorheading[ERCC X.25 (1984) Packet Level Protocol Software] @paragraph(Introductory Remarks) In the paper entitled "Implementation Details for Protocols on CSMA/CD LANs" [1], the JNT Ethernet Advisory Group describes guidelines for the UK Academic Community's transition to ISO OSI standards on a LAN (as well as for interworking with Wide Area Networks). To summarise, the OSI Connection-Oriented Network Service (CONS) is to be provided directly by the 1984 version of the X.25 packet level protocol in DTE-to-DTE mode of operation [2] supported by LLC2 [3]. The configurations within which this protocol set can be employed is described in reference [4] as @begin[verbatim] A single LAN A sequenced Bridged Area Network A LAN as an OSI subnetwork A single LAN or a sequenced Bridged Area Network connected to an X.25 Wide Area Network @end[verbatim] Aspects of the packet level protocol operation are described in references [1] and [5]. The following paragraphs describe briefly the X.25 software under development at ERCC. It is anticipated from the outset that the packet level software should be capable of both conforming to the JNT's requirements for CSMA/CD LANs and also be useable within the Wide Area Network context in interfacing to a DCE. (Whether @i(both) should be available simultaneously is a a matter for further discussion - there seems to be no major difficulty except that the link level procedures in the LAN and DTE/DCE cases differ in detail. In a similar vein, the question of whether a network level relay entity be incorporated is left for future development as it is not anticipated that an host would wish to suffer the overhead implied by LAN-WAN Gateway functionality.) There may also be a requirement to run this software in an X.25 (1980) environment. @paragraph(Interface to the Network Service and the Packet Level) The procedures for realisation of the OSI CONS primitives using X.25 (1984) protocol elements is described in reference [6]. The set of 'optional user facilities' required to support the CONS is presented there along with primitive to packet mapping and include: @begin[verbatim] Quality of Service: Throughput class negotiation Transit delay selection and indication * End-to-end transit delay negotiation * Minimum throughput class negotiation. Addressing: * Called and calling address extension. OSI support: Fast select Fast select acceptance. Expedited Data: * Expedited data negotiation facility. Confirmation: D-bit procedures. @end[verbatim] where the asterisk marks the CCITT-specified DTE facilities. The interface procedures will provide access to all these parameters except the Confirmation Request - in the initial version of the software, procedures associated with use of the D-bit will not be supported. For clarity, the definition of the interface procedures are appended to this note (C syntax). It should be remarked that the network layer software will not, in the first instance, check that the requested quality of service can be supported - this will be left until the evaluation period for parametrisation. In addition, during the coming phase of migration to the full OSI protocol layer set, there will be no concatenation of X.25 M-bit sequences into complete network service data units before passing the N-DATA indication to the user - that is, the NS user should consider the N-DATA indication as logically occurring when the end-of-sequence signal is observed. This conflicts somewhat with the specification but experience has demonstrated a need to protect the code from applications which can potentially send extremely large data units. Similarly, the NS user has access to the M-bit and the software will recognise this in preparing data frames for transmission. Some features which do not form part of the OSI network service interface will also be available (if requested) viz. negotiation of X.25 packet and window sizes, fast select with restricted response and visibility of the Q-bit. Strictly speaking, the packet and window sizes bear a relationship to the throughput class negotiation parameter, part of the quality of service set, but until evaluation studies of the software performance are undertaken, the dependence is not yet known. The provision of the Q-bit to the network service user is necessary to support X.29-like services over the OSI NS, described as mandatory in reference [1]. For completeness, reference [1] avers that several procedures described in ISO 8208 are not required - they will not therefore be supported in the first instance: @begin[verbatim] On-line facility registration facility Packet retransmission facility Sequence numbering modulo 128 DIAGNOSTIC packets (may be implemented for LAN) @end[verbatim] Other important features supported by the software are: @begin(itemize) Bothway switched virtual circuits (LIC=HIC=LTC and HTC=LOC=HOC). Default window and packet sizes of 2 and 128 octets, respectively. Timers and their associated procedures supported are @begin(verbatim) T20 (R20) (Restart request) T21 (Call request) T22 (R22) (Reset request) T23 (R23) (Clear request) T26 (Interrupt) @end(verbatim) @end(itemize) The procedures associated with T25 (Window rotation), T27 (Reject) and T28 (Registration request) are not supported, as noted above. T24 (Window status transmission) may be implemented as a means of suppression of packet level acknowledgment frames. The non-support of T25 requires some comment. In essence the code is designed to be 'lenient' in the case of flow control inhibition (see section 11.2 of reference 2). That is, a decision had to be made in order to to cater for the case when the remote station does not rotate the window fast enough to prevent expiry of T25 - ISO 8208 recommends @i(strongly) that high level protocols be used to effect recovery and this has been assumed. @paragraph(Interface to the Logical Link Level) No detailed specification can as be provided, but it is anticipated that the interface will take the general form of that described in reference [3] and the code is written to this specification. @paragraph(The Software Environment) At present, the current Ethernet service is supported by ERCC code providing access to ISO (Class 4 only) Transport Service over a null network layer and LLC1 procedures [7]. This code has already been mounted on both VAX* and UNIX** hosts within the Edinburgh environment. The implementation language is 'C'. There is a strong requirement, in the short to medium term, that both the current and the OSI CONS service be simultaneously supported within the same environment. Therefore, like the present Ethernet code, the CONS software will be installed within the UNIX kernel on the Gould. (This has certain ramifications such as non-preemption, ease of sharing data structures and so on.) It has proved possible to do this with only minimal changes to the current code - mainly structure re-definition and partitioning of a few crucial routines to accomodate protocol specific procedures e.g. X.25 requires more timers etc. As a brief summary of the salient points of the kernel software, incoming data can be passed synchronously upwards to 'user' software modules without queueing while user (or internal conditions) generate @i(events) which are enacted either during the call on the interface procedures or, if not possible, later, when the internal scheduler is activated by a clock tick. In this way, some of the disadvantages caused by waits in queues can be by-passed. The buffer scheme employed is assumed to be the so-called 'mbuf's described in reference [8]. This system, at least in theory, permits any length of data to be carried in a linked sequence of buffers in order to make economic use of available memory. @newpage @u(Definitions for Network Service Interface Routines and Procedures) The following paragraphs describe the services which are assumed to be made available by the user, and the interface routines provided by the X.25 packet level for that user. @u(Service Routines Provided by the NS User) Two routines are essential to the X.25 code, concerned with passing indications/confirmation primitives from the network service to the NS user: @begin(verbatim) int IND_toCNU( int u_func, int nsref, int userref, struct mbuf *buff_pointer); int user_on_NSAP( unsigned char *called_address, unsigned char *calling_address, int *userref ); @end(verbatim) @b(IND_toCNU) provides the means by which the X.25 code passes indications, confirmations and so on, to the NS user. In all calls, the network service reference, @i(nsref), and NS user's reference if known to the NS at that time, @i(userref), are quoted. The type of the indication is passed in @i(u_func) along with a pointer to any data. The list of indications etc which can be passed to the user are: @begin(verbatim) N_Data Data Indication N_EData Expedited Data Indication N_CI Connect Indication N_CC Connect Confirmation N_DI Disconnect Indication N_RI Reset Indication N_RC Reset Confirmation DTflow Release Pressure on Data Requests EDflow Release Pressure on Expedited Data Requests @end(verbatim) In only one instance is the returned value of the function important - the N-DATA.indication case described below. @b(user_on_NSAP) provides the means by which the X.25 code can ascertain a reference to be passed by IND_toCNU when dealing with connect indications. The user examines the called and calling NSAP (perhaps for authorisation etc.) and returns a result of zero for the case when the connect can be handled (in which case an @i(userref) will also be returned). A non-zero result indicates to the NS that the connect.indication procedure may not be carried any further. The non-zero values for return might be selected from the following for the OSI service (although any non-zero value will have the result of rejecting the connect indication): @begin(verbatim) 0XE8 - NSAP unknown (permanent condition) 0XE9 - NSAP unreachable (transient condition) @end(verbatim) @u(Network Service Interface Routines) All network service routines are implemented as functions which return a status value to report the success/failure of the current call. The general scheme adopted is that the returned integer result takes one of the following values: @begin(verbatim) 0 : success > 0 : failure (except in some 'details' routines) - 1 : catastrophy @end(verbatim) where 'catastrophy' denotes a call with parameter combinations which should ideally not occur, usually some fault in specification of the NS reference. The meaning of the other non-zero values is routine dependent and are described in the following discussion for each routine. @need(14) @b(N-CONNECT.request) @begin(verbatim) int N_conreq( int userref, int *nsref, unsigned char *called_addr, unsigned char *calling_addr, struct qosformat *qos, struct mbuf *NS_User_Data ); @end(verbatim) N_conreq is called to initiate a connect request. The routine parameters are: @begin(itemize) @i(userref:) A reference for identification which the NS will quote on all subsequent transactions concerning this connection; @i(nsref:) A reference which will be supplied by the NS; @i(called_/calling_addr:) Pointers to called and calling NSAP address; @i(qos:) A pointer to a quality of service record to request quality of service and/or X.25 parameter negotiation (see the section on qosformat below). If default values only are required, then this pointer may be null; @i(NS_User_Data:) A pointer to a buffer containing NS user data which is to be carried by the X.25 call request packet (and therefore up to 128 octets only). This may be null; @end(itemize) On successful return from the call, signalled by a zero result, a reference, which must be quoted on all further interface routine calls, is returned in @i(nsref). Thereafter, the caller should wait on either a disconnect (rejection) or a connect confirmation from the network service. The user may, of course, pre-empt and request disconnection, but no other service primitives are valid in this state. On failure, signalled by the non-zero result, it should be noted that any NS user data buffer still belongs to the caller. The returned non-zero results, indicating congestion, are: 0XE3 - Connection Rejection - reason unspecified (transient) @need(14) @b(N-CONNECT.indication) @begin(verbatim) Indication 'N_CI' passed via IND_toCNU (along with any NS user data), specific details obtained by calling: int N_CIdetails( int nsref, unsigned char *called_addr, unsigned char *calling_addr, struct qosformat *qos ); @end(verbatim) N_CIdetails is called to provide the parameters of the N-CONNECT.indication primitive. The routine parameters are: @begin(itemize) @i(nsref:) The reference which was provided in the interface indication call, and must henceforth be quoted on NS interface calls concerning this connection; @i(called_/calling_addr:) Pointers to character arrays into which the called and calling NSAP addresses will be placed. @i(qos:) A pointer to a record for reception of quality of service and X.25 parameter information. If the user is not interested, this pointer may be null. @end(itemize) The only values returned by this routines are zero (success) and (-1), the latter being catastrophic and due to the user supplying an incorrect reference. After reception of the connect indication, the user may respond by accepting or disconnecting (rejecting) the connection. It should be noted that the NS may pre-empt a response by a disconnect - the consequences of this in specifying user references in routines @i(user_on_NSAP) and @i(N_conrsp) should be noted. @need(14) @b(N-CONNECT.confirm) @begin(verbatim) Confirmation 'N_CC' passed via IND_toCNU (along with any NS_User_Data), specific details obtained by calling: int N_CCdetails( int nsref, unsigned char *responding_addr, struct qosformat *qos ); @end(verbatim) N_CCdetails is called to provide the parameters of the N-CONNECT.confirmation primitive. The routine parameters are: @begin(itemize) @i(nsref:) The reference which was provided in the N_conreq call; @i(responding_addr:) Pointer to a character array into which the responding address will be placed. @i(qos:) A pointer to a record for reception of quality of service and X.25 parameter information. If the user is not interested, this pointer may be null. @end(itemize) The only values returned by this routine are zero (success) and (-1), the latter being catastrophic and due to the user supplying an incorrect reference. After reception of this primitive, the connection enters the data transfer phase. @need(14) @b(N-CONNECT.response) @begin(verbatim) int N_conrsp( int userref, int nsref, unsigned char *responding_addr, struct qosformat *qos, struct mbuf *NS_User_Data ); @end(verbatim) N_conrsp is called to respond to a previous connect indication. The routine parameters are: @begin(itemize) @i(userref:) A reference for identification which the network service will quote on all further indications. (Note that this may, or may not be the same as the user reference passed in the call to the routine 'user_on_NSAP', it must be noted that the value passed in N_conrsp is the one which the NS will quote on all subsequent interface calls); @i(nsref:) The reference which was passed in the connect indication; @i(responding_addr:) Pointer to an array holding a responding NSAP address; @i(qos:) A pointer to a quality of service record to negotiate quality of service and/or X.25 parameters (see the section on qosformat below). If no negotiation is required, this pointer may be null; @i(NS_User_Data:) A pointer to a buffer containing NS user data which is to be carried by the X.25 call accept packet (and therefore up to 128 octets only). This may be null; @end(itemize) The only values returned by this routines are zero (success) and (-1), the latter being catastrophic and due to the user supplying an incorrect reference. After calling this routine, the connection enters the data transfer phase, but until the X.25 call accept packet has been sent, pressure will be exerted on NS user data. @need(14) @b(N-DATA.request) @begin(verbatim) int N_putdata( int nsref, unsigned char eonsdu, unsigned char setQbit, struct mbuf *buffer ); @end(verbatim) Called to request transmission of data. The routine parameters are: @begin(itemize) @i(nsref:) The NS reference identifying this connection. @i(eonsdu:) 1 or 0 depending on whether the NS user signals that this buffer is, respectively, the end of (equivalently sole part of) or part of a network service data unit. @i(setQbit:) 1 or 0 depending on whether the NS user signals that this data unit should or should not carry the X.25 Q-bit, respectively. (Note that this non-OSI feature is only required to support applications wishing to make use of the Q-bit.) @i(buffer:) Pointer to an mbuf sequence holding the data. @end(itemize) Acceptance of the buffer for transmission by the NS is signalled by a zero result while (-1) denotes catastrophy. A positive result indicates that the NS is exerting pressure on the data flow, and the buffer still belongs to the caller. Release of pressure will be signalled by reception of a @i(DTflow) indication via IND_toCNU. @need(14) @b(N-DATA.indication) @begin(verbatim) Indication 'N_Data' passed via IND_toCNU (along with the data pointer), specific details on the unit obtained by calling: N_DTdetails( struct mbuf *inbuffer, unsigned char *eonsdu, unsigned char *Qbitset ); @end(verbatim) The routine (macro) may be called to ascertain details about the data sequence pointed to by @i(inbuffer). @i(eonsdu) 0 or 1 signals, respectively, a fragment of or completion of a network service data unit. @i(Qbitset) 0 or 1 signals, respectively, that the X.25 Q-bit was not, was set on this data sequence. Note that these two signals are independent. As an aid to throughput, it is possible to return 'credit' for this data unit to the network service via the returned value of the IND_toCNU function. That is, if the NS user wishes to keep data flow open then a non-zero value (greater than zero) can be returned which has the effect of rotating the remote end's window for transmission. It should not be inferred that the NS user can immediately stop input by this means. In essence the NS user can only 'strangle' input by letting the remote end's X.25 transmission window close. If the returned value is 0 then it is assumed that, when ready, the NS user will provide credit by employing the routine @i(N_enableinput) described below. More detail is provided below. @need(10) @b(N-EXPEDITED DATA.request) @begin(verbatim) int N_putexpdata( int nsref, struct mbuf *buffer ); @end(verbatim) Called to request transmission of expedited data. The routine parameters are: @begin(itemize) @i(nsref:) The NS reference identifying this connection. @i(buffer:) Pointer to an mbuf sequence holding the data. @end(itemize) Acceptance of the buffer for transmission by the NS is signalled by a zero result while (-1) denotes catastrophy. A positive result indicates that the NS is exerting pressure on the expedited data flow, and the buffer still belongs to the caller. Release of pressure will be signalled by reception of a @i(EDflow) indication via IND_toCNU. @need(10) @b(N-EXPEDITED DATA.indication) @begin(verbatim) Indication 'N_EData' passed via IND_toCNU (along with the data pointer), there are no other parameters. @end(verbatim) @need(10) @b(N-RESET.request) @begin(verbatim) int N_rstreq( int nsref, unsigned char NSreason ); @end(verbatim) Called during the data transfer phase to initiate a reset procedure. The routine parameters are: @begin(itemize) @i(nsref:) The NS reference identifying this connection. @i(NSreason:) A reason for the reset procedure. Note that the other OSI parameter, 'originator', is implicitly set to the value N_USER. @end(itemize) If the request is accepted by the NS @i(viz) a zero result, the NS user should wait for a response to the request. Of course, the NS user can pre-empt the response with a disconnect request; similarly a disconnect indication may be received by the NS user. A (-1) result signifies catastrophy. Note that the requested reason will be transmitted as the X.25 reset request diagnostic code field. Strictly, one value is of end-to-end significance: @begin(itemize) 0XFA - Reset, user resynchronisation. @end(itemize) Note that any data received from the NS after initiation of this procedure should be discarded until the reset confirmation is received. @need(14) @b(N-RESET.indication) @begin(verbatim) Indication 'N_RI' passed via IND_toCNU, specific details obtained by calling: int N_RIdetails( int nsref, unsigned char *originator, unsigned char *NSreason ); @end(verbatim) N_RIdetails is called to provide the parameters of the N-RESET.indication primitive. The routine parameters are: @begin(itemize) @i(nsref:) The NS reference identifying the connection. @i(originator:) One of two values is passed : N_USER or N_PROVIDER depending on which party is deemed to have initiated the reset procedure. @i(NSreason:) A value is passed to identify the reason for initiation. This takes three values which are mapped from the X.25 resetting cause and diagnostic codes: @begin(verbatim) 0XE9 - Reset, reason unspecified, (originator N_PROVIDER); 0XEA - Reset, congestion, (originator N_PROVIDER); 0XFA - Reset, user resynchronisation, (originator N_USER). @end(verbatim) @end(itemize) A returned result of (-1) denotes catastrophy while @u(any) other value denotes success. For those user applications which require knowledge of the X.25 resetting cause and diagnostic codes, the result is constructed as @begin(verbatim) (cause << 8) + diagnostic. @end(verbatim) On reception of the reset indication, the user should reply either with a reset response, or possibly a disconnect request. @need(10) @b(N-RESET.confirm) @begin(verbatim) Confirmation 'N_RC' passed via IND_toCNU. There are no parameters. @end(verbatim) After reception of the confirmation, the NS user can assume that the reset procedure is complete, and the connection enters the data transfer phase. @need(10) @b(N-RESET.response) @begin(verbatim) int N_rstrsp( int nsref); @end(verbatim) Called to respond to a reset indication. The parameter @i(nsref) identifies the connection. A returned result of (-1) denotes catastrophy, while zero indicates success - in which case (to the NS user) the connection enters the data transfer phase. @need(14) @b(N-DISCONNECT.request) @begin(verbatim) N_disreq( int nsref, unsigned char NSreason, unsigned char *responding_addr, struct mbuf *NS_User_Data ); @end(verbatim) N_disreq is called to close the connection - note that this is potentially destructive. The routine parameters are: @begin(itemize) @i(nsref:) The NS reference identifying the connection. @i(NSreason:) A reason for disconnection (the implicit 'originator' is N_USER). @i(responding_addr:) Pointer to a character array containing (if required) the responding NSAP address. @i(NS_User_Data:) Pointer to an mbuf sequence containing user data to be carried by the X.25 clear request packet (and therefore a maximum of 128 octets). If not required, this pointer may be null. @end(itemize) A returned result of (-1) denotes catastrophy while after successful return (zero result), no more reference to this connection may be made by the NS user, nor will any outstanding primitives be indicated to the NS user. The @i(NSreason) parameter will be encoded in the X.25 clear request packet's diagnostic field. For information, values which are mapped one-to-one with OSI values are: @need(12) @begin(verbatim) 0XF1 - Disconnection, normal; 0XF2 - Disconnection, abnormal; 0XF3 - Disconnection, incompatible information in user data; 0XF4 - Rejection, reason unspecified, transient condition; 0XF5 - Rejection, reason unspecified, permanent condition; 0XF6 - Rejection, requested QOS not available, transient condition; 0XF7 - Rejection, requested QOS not available, permanent condition; 0XF8 - Rejection, incompatible information in user data; @end(verbatim) @need(14) @b(N-DISCONNECT.indication) @begin(verbatim) Indication 'N_DI' passed via IND_toCNU (along with any NS user data), specific details obtained by calling: int N_DIdetails( int nsref, unsigned char *originator, unsigned char *NSreason, unsigned char *responding_addr ); @end(verbatim) N_DIdetails is called to provide the parameters of the N-DISCONNECT.indication. The routine parameters are: @begin(itemize) @i(nsref:) The NS reference identifying the connection. @i(originator:) One of two values is passed : N_USER or N_PROVIDER depending on which party is deemed to have initiated disconnection. @i(NSreason:) A value is passed to identify the reason for disconnection. @i(responding_addr:) Pointer to a character array into which the responding NSAP address will be placed. @end(itemize) A returned result of (-1) denotes catastrophy while any other value denotes success. For those user applications which require knowledge of the X.25 clearing cause and diagnostic codes, the result is constructed as @begin(verbatim) (cause << 8) + diagnostic. @end(verbatim) After reception of the disconnect indication, no more reference may be made to this circuit, in particular, only within the body of the routine IND_toCNU will the call to N_DIdetails be successful. @need(5) @b(Data Control) The algorithm which the X.25 and interface code uses to control the flow of data to the local NS user is based on control of the X.25 virtual circuit's window. When the connection enters the data transfer phase, after completion of connect or reset procedures, the remote transmitter's window, Wr say, is wide open - a full window, Wr, data packets may be sent. Upon reception locally, these are passed immediately to the NS user - there is no queuing at the network level. That is, in this scheme, on entry to the data transfer state, the local NS user may be considered to have @b(pre-acknowledged) Wr data packets. To control further flow, the remote transmitter's window will not be rotated until the NS user gives permission through a 'credit' value to do so (other internal NS events may rotate the window, but such mechanisms do not effect this description). Specifically, by a credit equal to 'nnn', the NS user authorises 'nnn-more data units than are @i(already) credited'. Credit is passed to the NS level by calling: @need(6) @begin(verbatim) int N_enableinput( int nsref, int amount_of_credit ); @end(verbatim) where the routine parameters are: @begin(itemize) @i(nsref:) The network reference identifying the connection; @i(amount_of_credit:) The amount by which the NS user is willing for the remote window to rotate. It should not be negative - the remote window cannot be closed in this way. @end(itemize) N_enableinput returns (-1) for a catastrophic error and zero for success. For proper operation of this scheme, the NS user should, at some time, provide credit for every data unit received. Note that credit can also be given via the interface routine during an N-DATA.indication as described above. @u(Quality of Service and Extra X.25 Facilities) As mentioned in the specification of the interface routines concerned with the establishment of connections, the quality of service parameters are presented in 'qos'. For those NS user applications which require it, an 'extraformat' structure within 'qos' provides a window into some X.25 packet level facilities. The format of the two structures involved are: @begin(verbatim) struct extraformat { unsigned char restrictresponse; unsigned char locpacket, rempacket; unsigned char locwsize , remwsize; }; struct qosformat { unsigned char reqtclass; unsigned char locthroughput, remthroughput; unsigned char reqtransitdelay; unsigned short transitdelay; unsigned char reqminthruput; unsigned char locminthru, remminthru; unsigned char reqendtoend; unsigned short cumulative, target, acceptable; unsigned char reqexpedited; unsigned char reqackservice; struct extraformat *xtras; }; @end(verbatim) The several fields in these structures are: @begin(itemize) @b(Throughput Class.) If the throughput negotiation parameter is selected, then @i(reqtclass) is non-zero, in which case the fields @i(locthroughput) and @i(remthroughput) contain, respectively, the four-bit throughput encoding for the directions local-to-remote and remote-to-local. @b(Transit Delay.) If the transit delay parameter is selected, then @i(reqtransitdelay) is non-zero, in which case the field @i(transitdelay) contains the 16-bit value. @b(Minimum Throughput Class.) If the minimum throughput negotiation parameter is selected, then @i(reqminthruput) is non-zero, in which case the fields @i(locminthru) and @i(remminthru) contain, respectively, the four-bit throughput encoding for the directions local-to-remote and remote-to-local. @b(End-to-End Transit Delay.) If the end-to-end transit delay facility is selected, then the field @i(reqendtoend) takes a value 1 to 3 depending on which set are required/indicated: @begin(enumerate) Only the cumulative value is present as a 16-bit value in @i(cumulative). As well as the cumulative value, as above, the field @i(target) contains the 16-bit value of the desired (target) end-to-end delay. As well as the cumulative and target end-to-end delay values, as above, the field @i(acceptable) contains the 16-bit value of the minimum acceptable value for the end-to-end transit delay. @end(enumerate) Note that the values 2 and 3 pertain only to N-CONNECT.indications and requests, and do not appear in confirmation or response interface calls. @b(Use of Expedited Data.) If expedited data is required/selected, then the field @i(reqexpedited) is non-zero. @b(Receipt Acknowledgement Service.) If the receipt acknowledgement service is to be employed, the field @i(reqackservice) is non-zero. N.B. this field is only presented for completeness, this facility is not supported by this code. @b(xtras.) This field contains the X.25 specific features which are described below. @b(X.25 Restricted Response.) If the response to a connect.indication or request is to be a disconnect, then the field @i(restrictresponse) is non-zero. @b(X.25 Packet Size Negotiation.) If the fields @i(locpacket) and @i(rempacket) are non-zero, then they contain indicated/negotiated packet sizes, respectively for the directions local-to-remote and remote-to-local. @b(X.25 Window Size Negotiation.) If the fields @i(locwsize) and @i(remwsize) are non-zero, then they contain indicated/negotiated window sizes, respectively for the directions local-to-remote and remote-to-local. @end(itemize) It should be noted that, at the present time, none of the values requested or negotiated are policed by the NS interface code. @newpage @newpage @u(Configuration Options) The X.25 code has several parameters which may be adjusted according to the local environment of the LAN. At the present time, these parameters are selected and installed at compile time. All options are held in the configuration structure 'xcfg' which is described by the structure: @begin(verbatim) struct x25cfgformat { /* X25 PLP facility definitions */ unsigned char DEFPKTSIZE; unsigned char MAXPKTPAR; unsigned char DEFWSIZE; unsigned char ASKPSIZE; unsigned char ASKWSIZE; unsigned char ASKEXPDATA; unsigned char ACCREVCHARGES; short MAXNSDULEN; /* X25 PLP timer and retransmission values */ float Tresolution; short T20value; short T21value; short T22value; short T23value; short Tvalue; short T25value; short T26value; short ACKDELAY; short idlevalue; short connectvalue; unsigned char R20value; unsigned char R22value; unsigned char R23value; /* X25 PLP virtual circuit ranges */ short HIC, LIC; short HTC, LTC; short HOC, LOC; short NICchannels; short NTCchannels; short NOCchannels; short Nochnls; /* Link level local address */ unsigned char local_address[MAXLOCTETS+1]; }; @end(verbatim) Each of these elements is described in the following paragraphs. @b(DEFPKTSIZE) On a particular LAN, or in a DTE/DCE environment, this specifies the value of the default packet size, which may be nonstandard, provided the value is agreed between all communicating parties on the LAN or between the DTE and DCE. The usual standard value is 7 implying a default data packet size for each direction of transmission of 128 ( 1 << 7 ) octets. @b(MAXPKTPAR) As a local option, the system manager selects the maximum size of data packets which are acceptable. That is, on any incoming X.25 call, a value for the packet size parameter greater than MAXPKTPAR will be negotiated down to this value when the call is accepted. According to the ISO specification, the largest value is 12, implying a data packet size 4096 octets (1<<12), but note that a size of 128 must always be offered. Thus MAXPKTPAR is bounded in the range >=7 and <=12. @b(DEFWSIZE) On a particular LAN, or in a DTE/DCE environment, this specifies the value of the default window size, which may be nonstandard provided the value is agreed between all communicating parties on the LAN or between the DTE and DCE. @b(ASKPSIZE) In order to cater for the case when the NS user software wishes to either supply a NULL pointer for the qos parameter or zero values for the 'extra' parameters locpacket and/or rempacket, in connect.requests, the local system manager supplies a value to be used for packet sizes. @b(ASKWSIZE) In order to cater for the case when the NS user software wishes to either supply a NULL pointer for the qos parameter or zero values for the 'extra' parameters locwsize and/or remwsize, in connect.requests, the local system manager supplies a value to be used for window sizes. The usual standard value is 2 for each direction of data transmission. @b(ASKEXPDATA) In order to cater for the case when the NS user software wishes to supply a NULL pointer for the qos parameter (i.e. no explicit value for reqexpedited) in connect.requests, the local system manager supplies a value to be used - 0 for non-use, non-zero otherwise. @b(ACCREVCHARGES) A value of zero implies that any requests for reverse charging in incoming X.25 connect indications will cause rejection of the call. Non-zero indicates that reverse charging will be accepted. @b(MAXNSDULEN) The X.25 code will attempt to concatenate data packets marked with the 'More Data Mark' (M-bit) into a single network service data unit. However, in order to protect the local implementation, the system manager can specify a maximum length beyond which concatenation will be stopped and the data currently held will be passed to the NS user (with, of course, the eonsdu parameter zero - see the interface specification). @b(Tresolution) specifies the resolution of the clock - for information only. @b(T20value) specifies, in number of ticks, the value of DTE timer parameter T20, the Restart Request Response Timer. @b(T21value) specifies, in number of ticks, the value of DTE timer parameter T21, the Call Request Response Timer. @b(T22value) specifies, in number of ticks, the value of DTE timer parameter T22, the Reset Request Response Timer. @b(T23value) specifies, in number of ticks, the value of DTE timer parameter T23, the Clear Request Response Timer. @b(Tvalue) This field is related, but does not correspond exactly, to the DTE Window Status Transmission Timer, T24. It specifies the maximum time interval over which acknowledgements of data received from the remote transmitter will be withheld. Moreover, after expiry of this timer, any withheld acknowledgements will be carried by an X.25 level 3 'receiver-not-ready' control packet. This timer is implemented to ensure that non-receipt of acknowledgement by the remote transmitter does not cause resets within the virtual circuit. It should be exphasised that the implementation of this timer does not imply transmission of window status @i(every) 'Tvalue' ticks. @b(T25value) specifies, in number of ticks, the value of DTE timer parameter T25, the Window Rotation Timer. @b(T26value) specifies, in number of ticks, the value of DTE timer parameter T26, the Interrupt Response Timer. @b(ACKDELAY) The X.25 code attempts to suppress the generation of level 3 'receiver-ready' control packets - acknowledgement carried by data or multiple acknowledgemnts is preferred over the case when each data packet is explicitly and separately acknowledged. Thus, ACKDELAY specifies the maximum number of ticks over which a pending acknowledgement will be withheld. It also serves a dual purpose in that, should the buffer pool of the local DTE become classed as busy, the pool status will be examined every 'ACKDELAY' ticks to ascertain whether stress has been relieved. Therefore, this timer must not be zero. @b(idlevalue) is the number of ticks over which a link-level connection associated with no connections will be maintained. @b(connectvalue) specifies the number of ticks over which the DTE/DCE resolution phase be complete - implemented in order to prevent the (unlikely) event that the two packet level entities cannot resolve their DTE/DCE nature. On expiry of this timer, the link connection will be disconnected and all pending connections aborted. @b(R20value) specifies the DTE Restart Request Retransmission Count. @b(R22value) specifies the DTE Reset Request Retransmission Count. @b(R23value) specifies the DTE Clear Request Retransmission Count. @b(LIC to HIC, LTC to HTC, LOC to HOC) specify the ranges of logical channels which are classed as assigned respectively to one-way @b(i)ncoming logical @b(c)hannels, @b(t)wo-way logical @b(c)hannels and one-way @b(o)utgoing logical @b(c)hannels. In a DTE/DTE environment, one of the interacting pairs views these ranges as a DCE e.g. LIC to HIC are viewed as one-way @i(outgoing). Note that HxC = LxC = 0 denotes no channels in that grouping. @b(NICchannels, NTCchannels, NOCchannels and Nochnls) count the number of logical channels assigned - this is calculated from LIC, HIC etc and can be changed only by altering these ranges. @b(local_address) Holds the local part of the LSAP address for this X.25 packet level protocol entity. At this time, it is assumed to be a maximum of 'MAXLOCTETS' octets with an associated length byte held in local_address[0]. @newpage @paragraph(References) @begin[itemize] 1. Implementation Details for protocols on CSMA/CD LANs, A report prepared by the JNT Ethernet Advisory Group. JNT/CSMA/CD LAN(85), August 1985. 2. Data Communication - X.25 packet level protocol for data terminal equipment. ISO 8208. 3. IEEE DS 802.2. Logical Link Control (1985). 4. Specification of Protocols for use on a Local Area Network to provide the OSI Network Service. Part 1, General. ISO DP 8880/1 April 1985. Part 2, Use of the X.25 Packet Level Protocol to provide the Connection-mode Network Service, ISO DP 8880/2 April 1985. 5. Information Processing Systems - Data Communications - Use of the X.25 Packet Level Protocol in Local Area Networks. ISO DP 8881, April 1985. 6. Use of X.25 to Provide the OSI Connection-Oriented Network Service. ISO DP 8878, February 1985. 7. Documented by W. Byers (VAX) and A. Hamilton (UNIX). 1985 8. UNIX Programmer's Manual. 4.2 Berkeley Software Distribution, Volume 2c, Virtual VAX-11 Version, August 1983. @end[itemize] @begin(verbatim) **UNIX is a trademark of AT&T Bell Laboratories. *VAX is a trademark of Digital Equipment Corporation. George Howat, ERCC, October 1985. @end(verbatim)