|
DataMuseum.dkPresents historical artifacts from the history of: CP/M |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CP/M Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 48512 (0xbd80)
Types: RcTekst
Names: »99109973.WP«
└─⟦7fab0c8ae⟧ Bits:30005866/disk3.imd Dokumenter i RcTekst format (RCSL 99-1-*)
└─⟦this⟧ »99109973.WP«
╱04002d4e0c00060000000003014831600000000000000000000000000000000000000000000000002a34414b555f69737d8791ffffffffff04╱
↲
╞ __________________________↲
╞ RCSL No.:╞ 991 09973↲
╞ Edition:╞ December 1984↲
╞ Authors: ╞ Ejvind Lynning (ed.)↲
╞ ╞ John Svensson↲
╞ ╞ Peter Holm↲
╞ ╞ Jesper A. Tågholt↲
↲
↲
↲
↲
FOR INTERNAL USE↲
↲
↲
↲
↲
________________________________________________________________________↲
↲
Title:↲
↲
┆06┆RCLLC↲
┆06┆Protocol for Logical Link Control↲
┆06┆in RC Local Area Networks↲
↲
↲
________________________________________________________________________↲
════════════════════════════════════════════════════════════════════════
↓
┆06┆i↲
↲
↲
↲
┆a1┆TABLE OF CONTENTS PAGE↲
╱04002d4e0c0006000000000301483160000000000000000000000000000000000000000000000000050a11191e464b555f69737dffffffff04╱
╱04002d4e0c00060000000003014831600000000000000000000000000000000000000000000000002a34414b555f69737d8791ffffffffff04╱
↓
↲
↲
1.╞ INTRODUCTION ................................................... 1↲
↲
2.╞ FUNDAMENTAL CONCEPTS ........................................... 3↲
↲
3.╞ SERVICE INTERFACES ............................................. 5↲
╞ 3.1╞ MAC Service ...............................................╞ 5↲
╞ 3.2╞ RCLLC Services ............................................╞ 6↲
╞ ╞ 3.2.1╞ SAP Activation and Deactivation ....................╞ 6↲
╞ ╞ ╞ 3.2.1.1╞ ACTIVATE.request ...........................╞ 6↲
╞ ╞ ╞ 3.2.1.2╞ ACTIVATE.confirm ...........................╞ 7↲
╞ ╞ ╞ 3.2.1.3╞ DEACTIVATE.request .........................╞ 7↲
╞ ╞ ╞ 3.2.1.4╞ DEACTIVATE.confirm .........................╞ 8↲
╞ ╞ 3.2.2╞ Loop-back Test Service .............................╞ 8↲
╞ ╞ ╞ 3.2.2.1╞ TEST.request ...............................╞ 8↲
╞ ╞ ╞ 3.2.2.2╞ TEST.confirm ...............................╞ 9↲
╞ ╞ ╞ 3.2.2.3╞ TEST.indication ............................╞ 9↲
╞ ╞ 3.2.3╞ Type 1 Service .....................................╞ 10↲
╞ ╞ ╞ 3.2.3.1 UDATA.request ..............................╞ 10↲
╞ ╞ ╞ 3.2.3.2╞ UDATA.indication ...........................╞ 11↲
╞ ╞ 3.2.4╞ Client Network Service .............................╞ 11↲
╞ ╞ ╞ 3.2.4.1╞ CONNECT.indication .........................╞ 12↲
╞ ╞ ╞ 3.2.4.2╞ DISCONNECT.indication ......................╞ 13↲
╞ ╞ ╞ 3.2.4.3╞ DISCONNECT.acknowledge .....................╞ 13↲
╞ ╞ ╞ 3.2.4.4╞ DATA.request ...............................╞ 13↲
╞ ╞ ╞ 3.2.4.5 DATA.confirm ............................... 14↲
╞ ╞ ╞ 3.2.4.6╞ DATA.indication ............................╞ 14↲
↲
4.╞ RCLLC PROCEDURES ............................................... 15↲
╞ 4.1╞ Type 1 Procedures .........................................╞ 15↲
╞ ╞ 4.1.1╞ Unacknowledged Data Transfer .......................╞ 15↲
╞ ╞ 4.1.2╞ Loop-back Test Procedure ...........................╞ 16↲
╞ ╞ 4.1.3╞ Station Identification Exchange ....................╞ 16↲
╞ 4.2╞ Procedures for Client Network Service .....................╞ 17↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆06┆ii↲
↲
↲
↲
┆a1┆TABLE OF CONTENTS (cont.) PAGE↲
↲
↲
5. RCLLC PROTOCOL ELEMENTS ........................................ 23↲
╞ 5.1╞ Type 1 Protocol Elements .................................. 25↲
╞ ╞ 5.1.1╞ UI (Unnumbered Information) ........................╞ 25↲
╞ ╞ 5.1.2 XID (eXchange IDentification) ......................╞ 26↲
╞ ╞ 5.1.3╞ TEST ...............................................╞ 26↲
╞ 5.2╞ Protocol Elements for Client Network Service ..............╞ 26↲
╞ ╞ 5.2.1╞ ACTIVE_SAP .........................................╞ 26↲
╞ ╞ 5.2.2╞ RESET ..............................................╞ 27↲
╞ ╞ 5.2.3╞ RACK ...............................................╞ 28↲
╞ ╞ 5.2.4╞ DATA ...............................................╞ 28↲
╞ ╞ 5.2.5╞ ACK ................................................╞ 28↲
↲
↲
┆a1┆APPENDICES↲
↲
A. References .....................................................╞ 30↲
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆RCLLC Protocol┆05┆Page ┆0b┆↲
┆a1┆1. INTRODUCTION↲
↲
This document is the reference definition of the protocol for logical ↓
link control in an RC local area network, the ┆a1┆RCLLC protocol┆e1┆. The ↓
protocol applies to the intercommunication between those stations ↓
attached to such a local area network which are RC products. It does not ↓
rule out the attachment of other manufacturers' products to the same ↓
network, nor the cooperation between RC products and such other ↓
products.↲
↲
In order to place the protocol in proper context, a description of the ↓
service provided by the RCLLC layer and of the behavior of RCLLC ↓
entities is also given. The description of the RCLLC service is to be ↓
understood in an abstract sense and should not be interpreted as a ↓
prescription for an implementation. In particular,↲
↲
╞ - ┆84┆some of the service primitives may be statically implemented, i.e. ↓
┆19┆┆86┆┄┄as initializations, which may not require any interaction between ↓
┆19┆┆86┆┄┄entities;↲
╞ - ┆84┆some stations may offer only a subset of the complete RCLLC ↓
┆19┆┆86┆┄┄service.↲
↲
The protocol and service defined in this document form an extension to ↓
the proposed ISO LLC type 1 protocol and service (ref. 1), viz.:↲
↲
╞ - ┆84┆all frames which are valid according to the RCLLC protocol are ↓
┆19┆┆86┆┄┄also valid ISO LLC type 1 frames;↲
╞ - ┆84┆RCLLC adds protocol functions and interface service functionality ↓
┆19┆┆86┆┄┄to ISO LLC type 1 in a fashion which one might choose to consider ↓
┆19┆┆86┆┄┄as a sublayer added on top of an LLC type 1 sublayer.↲
↲
The services of LLC type 1 are data transfer on connectionless data ↓
links, allowing multiple independent clients within each station, plus ↓
facilities for point-to-point loop back test traffic.↲
↲
The essential service of the RCLLC layer, which constitutes an extension ↓
to the type 1 service, is called ┆a1┆client network service┆e1┆. This service ↓
comprises the dynamic configuration, maintenance and supervision of ↓
┆8c┆┆83┆┆c8┆↓
multiple independent networks of clients. Connection-based data transfer ↓
with sequence control and retransmission to avoid loss of or damage to ↓
data is performed between any pair of clients belonging to the same ↓
client network.↲
↲
Two types of client networks are foreseen and specifically catered for ↓
in the protocol design:↲
↲
1) ┆84┆IMC networks (refs. 3,4) which may involve a wide variety of RC ↓
┆19┆┆83┆┄┄products. The (RCLLC) clients in an IMC network are the IMC nodes;↲
2) ┆84┆CCP/M DR NET (ref. 5) networks in which the stations are RC750 ↓
┆19┆┆83┆┄┄Personal Computers. Each of these may also contain an IMC node and ↓
┆19┆┆83┆┄┄thus belong to two client networks.↲
↲
Like the ISO LLC protocol the RCLLC protocol assumes that the services ↓
of a Medium Access Control layer are available. The services of this ↓
layer are defined so as to be independent of the actual medium. In ↓
addition to transmission of frames to a specific station a multicast ↓
function must be provided.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆2. FUNDAMENTAL CONCEPTS↲
↲
The following terms are used in this document with their standard ↓
meaning as defined in the ISO model for Open Systems Interconnection ↓
(ref. 2): station, layer, entity, peer, protocol, service primitive, ↓
data link, connection.↲
↲
Further concepts and terminology which are not necessarily found in the ↓
ISO model, but used in the present document, are defined in the ↓
following:↲
↲
An ┆a1┆RCLLC station┆e1┆ is a station which is attached to the local area ↓
network and hosts an RCLLC entity that communicates with peer entities ↓
in other RCLLC stations according to the RCLLC protocol. A station which ↓
supports only the LLC type 1 protocol and not the full RCLLC protocol is ↓
not considered an RCLLC station. Until the RCLLC protocol is adopted by ↓
other manufacturers, an RCLLC station will be the same as an RC product ↓
attached to the network.↲
↲
The ┆a1┆M┆e1┆edium ┆a1┆A┆e1┆ccess ┆a1┆C┆e1┆ontrol (MAC) layer is the only protocol layer between ↓
the RCLLC layer and the physical network. Each RCLLC station contains ↓
precisely one MAC entity and one RCLLC entity. The ┆a1┆station address┆e1┆ is a ↓
unique address which identifies the station within the local area ↓
network. It follows that the station address is also a unique address of ↓
the RCLLC entity.↲
↲
The data units that are transmitted among RCLLC entities using the MAC ↓
service are called ┆a1┆RCLLC protocol elements┆e1┆.↲
↲
A ┆a1┆client┆e1┆ is an RCLLC-user, i.e. an entity making use of the RCLLC ↓
service and located in the layer above the RCLLC layer.↲
↲
An RCLLC ┆a1┆S┆e1┆ervice ┆a1┆A┆e1┆ccess ┆a1┆P┆e1┆oint (SAP) is the (logical) point at which a ↓
client accesses the RCLLC service. Within an RCLLC station each SAP is ↓
assigned a ┆a1┆local SAP address┆e1┆ in the range 1..63. The ┆a1┆complete SAP ↓
┆19┆┄┄┆84┆address┆e1┆ is the pair (station address, local SAP address) which uniquely ↓
identifies a SAP within the local area network.↲
↲
┆8c┆┆83┆┆c8┆↓
A SAP can be ┆a1┆inactive┆e1┆, in which case it is effectively unknown to the ↓
RCLLC layer so that all data and control information addressed to it is ↓
discarded; or it can be ┆a1┆active┆e1┆. An active SAP can be used to obtain ↓
either type 1 service or client network service, but not both.↲
↲
The RCLLC layer maintains a number of logical ┆a1┆client networks┆e1┆. A client ↓
network has a ┆a1┆network number┆e1┆ (within the local area network), which must ↓
be in the range 1..63, and comprises all active SAPs within RCLLC ↓
stations on the local area network whose local SAP addresses are equal ↓
to this number, and for which client network service has been requested.↲
↲
For all RC local area networks client network number 1 is assigned to an ↓
IMC network, i.e. the IMC nodes in the RCLLC stations of a local area ↓
network will all access the RCLLC service using a local SAP address of ↓
1. Similarly, client network number 2 is used for DR NET.↲
↲
Associated with each client network within a local area network is a ↓
multicast address which delimits the RCLLC stations that take part in ↓
the client network from all other stations on the network; i.e. a frame ↓
which is transmitted on the local area network with this multicast ↓
address should be received by (the MAC entity within) a station if and ↓
only if the station is an RCLLC station containing a SAP belonging to ↓
the client network.↲
↲
Each SAP belonging to a client network has an associated ┆a1┆SAP mask┆e1┆. The ↓
SAP mask is a 16-bit word. Two SAP masks ┆a1┆match┆e1┆ if at least one bit ↓
position contains a one in both masks, i.e. if a logical AND-operation ↓
yields a non-zero result. The RCLLC layer will maintain connections ↓
between all pairs of SAPs belonging to the same client network whose ↓
masks match.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆3. SERVICE INTERFACES↲
↲
The MAC layer is the foundation on which the RCLLC layer is built, and ↓
its service is therefore described briefly.↲
↲
The description of the RCLLC layer goes into much more detail, because ↓
there is a very direct relationship between the RCLLC service as it ↓
appears in the individual service primitives and the elements and ↓
procedures which constitute the RCLLC protocol. The description of the ↓
RCLLC service also forms a point of reference for the definition of ↓
protocols for services to be built on top of the RCLLC layer.↲
↲
↲
┆a1┆3.1 MAC Services↲
↲
The function performed by the MAC layer is to accept from an RCLLC ↓
entity a MAC service data unit, to transmit it to one, several ↓
(multicast), or all stations in the network, and in the receiving ↓
station(s) to deliver the unit to the destination RCLLC entity(ies).↲
↲
In the case of a CSMA/CD type network the MAC service includes retrans┄↓
mission following a detected collision.↲
↲
There is no guarantee that a MAC service data unit which is transmitted ↓
from one station on a network is received at the destination station(s).↲
↲
Each MAC entity is sensitive to its station address and possibly one or ↓
more multicast addresses, i.e. addresses of groups of stations to which ↓
the station belongs. Only MAC service data units transmitted with one of ↓
these addresses or the broadcast address (if applicable) will be ↓
received by the MAC entity.↲
↲
Padding of frames containing MAC service data units in order to reach a ↓
minimum size required by the type of physical network in question is ↓
performed by the MAC layer. The padding is removed again before ↓
delivery.↲
↲
┆8c┆┆83┆┆bc┆↓
A network dependent maximum size for MAC service data units is also ↓
enforced by the MAC layer, i.e. data units exceeding the maximum size ↓
will not be transmitted, and the receiver part of a MAC entity will ↓
discard all incoming frames that would yield a data unit longer than the ↓
maximum size.↲
↲
The RCLLC layer uses the MAC service by transmitting each RCLLC protocol ↓
element as a MAC service data unit.↲
↲
↲
┆a1┆3.2 RCLLC Services↲
↲
The RCLLC services are obtained by a client through an active SAP. A SAP ↓
can be used either for type 1 service or for client network service, but ↓
not for both. The loop-back test facility is available regardless of the ↓
choice of type 1 or client network service.↲
↲
↲
┆a1┆3.2.1 SAP Activation and Deactivation↲
↲
There are four primitives to request activation and deactivation of a ↓
SAP and to confirm the processing of these requests. They are described ↓
in the following subsections.↲
↲
↲
┆a1┆3.2.1.1 ACTIVATE.request↲
↲
The primitive which requests the activation of a SAP is passed from a ↓
client to the RCLLC entity.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆specifies the local SAP address of the SAP to be ↓
┆19┆┆93┆┄┄activated.↲
service_type╞ ┆84┆specifies whether type 1 service or client network ↓
┆19┆┆93┆┄┄service is requested; the following two parameters ↓
┆19┆┆93┆┄┄are only present if client network service is ↓
┆19┆┆93┆┄┄requested.↲
┆8c┆┆83┆┆c8┆↓
SAP_mask╞ ┆84┆specifies the SAP mask used to prevent establishment ↓
┆19┆┆93┆┄┄of undesired connections, cf. section 4.↲
client_info╞ ┆84┆is a data unit which is transmitted and passed to the ↓
┆19┆┆93┆┄┄remote client in the CONNECT_indication primitive ↓
┆19┆┆93┆┄┄whenever a connection is established between the ↓
┆19┆┆93┆┄┄activated SAP and a remote SAP.↲
↲
↲
┆0e┆↓
┆a1┆3.2.1.2 ACTIVATE.confirm↲
↲
The primitive which is issued in response to an ACTIVATE.request ↓
primitive is passed from the RCLLC entity to the requesting client.↲
┆0f┆↓
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆is the local SAP address of the SAP in question as ↓
┆19┆┆93┆┄┄specified in the request.↲
result╞ ┆84┆indicates whether the SAP was successfully activated.↲
↲
When a SAP has been activated for type 1 service UDATA.request primi┄↓
tives may be issued requesting the transmission of data.↲
↲
When a SAP has been activated for client network service, the RCLLC ↓
layer will automatically begin to establish the appropriate connections. ↓
As each connection is established, the client will be informed by means ↓
of a CONNECT.indication primitive and may subsequently request trans┄↓
mission of data by issuing DATA.request primitives.↲
↲
In either case, once a SAP has been activated, the client may issue the ↓
TEST.request primitive to request a loop-back test.↲
↲
↲
┆a1┆3.2.1.3 DEACTIVATE.request↲
↲
The primitive which requests the deactivation of a SAP is passed from a ↓
client to the RCLLC entity.↲
↲
┆8c┆┆83┆┆bc┆↓
┆0e┆↓
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆specifies the local SAP address of the SAP to be ↓
┆19┆┆93┆┄┄deactivated.↲
┆0f┆↓
↲
↲
┆a1┆3.2.1.4 DEACTIVATE.confirm↲
↲
The primitive which is issued in response to a DEACTIVATE.request primi┄↓
tive is passed from the RCLLC entity to the requesting client.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆is the local SAP address of the SAP in question as ↓
┆19┆┆93┆┄┄specified in the request.↲
↲
↲
┆a1┆3.2.2 Loop-back Test Service↲
↲
The loop-back test facility allows a client to request a test of the ↓
transmission path between the local RCLLC entity and one or more remote ↓
RCLLC entities without requiring the participation of any remote ↓
client(s). This is done by transmitting a TEST protocol element ↓
(command) to the specified RCLLC entity/entities to which it/each of ↓
them must respond by transmitting a TEST protocol element (response) ↲
addressed to the requesting client (SAP).↲
↲
Notice: No indication is given if the responding protocol element fails ↓
to arrive from any or all of the RCLLC entities addressed in the ↓
TEST.request primitive.↲
↲
↲
┆a1┆3.2.2.1 TEST.request↲
↲
The primitive, which requests that one or more transmission paths be ↓
tested, is passed from a client to the RCLLC entity.↲
↲
┆8c┆┆83┆┆bc┆↓
┆0e┆↓
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ is the local SAP address.↲
┆0f┆↓
rem_addr╞ ┆84┆is the station address of the remote RCLLC entity; a ↓
┆19┆┆93┆┄┄multicast or broadcast address may be used in place ↓
┆19┆┆93┆┄┄of a specific station address to request testing of ↓
┆19┆┆93┆┄┄multiple transmission paths.↲
tdu╞ ╞ ┆84┆test data unit, transmitted in the information field ↓
┆19┆┆93┆┄┄of the exchanged protocl elements.↲
↲
↲
↲
┆a1┆3.2.2.2 TEST.confirm↲
↲
The primitive, which confirms that the transmission path between the ↓
local RCLLC entity and one remote RCLLC entity has been tested as ↓
requested by a previous TEST.request primitive, is passed from the RCLLC ↓
entity to the client.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ is the local SAP address.↲
rem_addr╞ is the station address of the remote RCLLC entity.↲
result╞ ┆84┆indicates how the test went, e.g. 'no problems', 'too ↓
┆19┆┆93┆┄┄many collisions', or 'received protocol element was ↓
┆19┆┆93┆┄┄damaged'.↲
↲
↲
┆a1┆3.2.2.3 TEST.indication↲
↲
The primitive, which indicates that a TEST protocol element addressed to ↓
the local SAP has been received, is passed from the RCLLC entity to the ↓
client.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
dest_addr╞ ┆84┆is the destination address of the received protocol ↓
┆19┆┆93┆┄┄element, consisting of↲
┆8c┆┆83┆┆c8┆↓
╞ ╞ 1) ┆84┆the local station address, or a multicast address ↓
┆19┆┆96┆┄┄to which the station is sensitive, or the ↓
┆19┆┆96┆┄┄broadcast address, and↲
╞ ╞ 2) the local SAP address.↲
src_addr╞ ┆84┆is the complete address of the source SAP or RCLLC ↓
┆19┆┆93┆┄┄entity, consisting of↲
╞ ╞ 1) station address, and↲
╞ ╞ 2) ┆84┆source SAP address or null address indicating the ↓
┆19┆┆96┆┄┄protocol element originated from the remote RCLLC ↓
┆19┆┆96┆┄┄entity.↲
↲
Note that a TEST.request primitive issued by a client in an RCLLC ↓
station does not cause this primitive to be generated in remote RCLLC ↓
station(s), as the protocol element (TEST command) which is transmitted ↓
in this case is not addressed to a SAP, but to one or more remote RCLLC ↓
entities.↲
↲
↲
┆a1┆3.2.3 Type 1 Service↲
↲
Type 1 service comprises unacknowledged connectionless data transfer ↓
between SAPs.↲
↲
↲
┆a1┆3.2.3.1 UDATA.request↲
↲
The primitive, which requests transmission of an RCLLC service data ↓
unit, is passed from a client to the RCLLC entity.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ is the local SAP address.↲
dest_addr╞ ┆84┆is the complete address of the destination SAP(s), ↓
┆19┆┆93┆┄┄where the station address may be a multicast address ↓
┆19┆┆93┆┄┄or the broadcast address.↲
l_sdu╞ is the service data unit to be transmitted.↲
service_class╞ ┆84┆specifies the priority desired for the data unit ↓
┆19┆┆93┆┄┄transfer; its effect is unspecified.↲
↲
↲
┆8c┆┆83┆┆e0┆↓
┆0e┆↓
┆a1┆┆a1┆3.2.3.2 UDATA.indication↲
↲
The primitive, which is used to deliver a received RCLLC service data ↓
unit, is passed from the RCLLC entity to the client.↲
┆0f┆↓
↲
┆a1┆Parameters┆e1┆:↲
↲
dest_addr╞ ┆84┆is the complete address of the destination SAP(s), ↓
┆19┆┆93┆┄┄where the station address may be a multicast address ↓
┆19┆┆93┆┄┄or the broadcast address.↲
src_addr╞ is the complete address of the source SAP.↲
l_sdu╞ is the received service data unit.↲
↲
↲
┆a1┆3.2.4 Client Network Service↲
↲
The RCLLC layer automatically establishes and maintains a connection ↓
between each pair of SAPs belonging to the same client network, except ↓
when the connection is excluded because the SAP masks do not match.↲
↲
When a SAP is activated, connections will be established to those remote ↓
SAPs which were already active. The (local) client will receive a ↓
CONNECT.indication primitive for each connection when it has been ↓
established. Similarly the remote clients will each receive a ↓
CONNECT.indication primitive.↲
↲
When a connection has been established, both clients may request the ↓
transmission of RCLLC service data units by issuing DATA.request ↓
primitives. A received data unit is passed to the client at the ↓
destination SAP by means of a DATA.indication primitive.↲
↲
The order in which RCLLC service data units are passed to the RCLLC ↓
layer for transmission on a connection is preserved to the point of ↓
delivery. RCLLC service data units are delivered free of transmission ↓
errors.↲
↲
When a SAP is deactivated, either because of a request or because the ↓
station in which it exists ceases to operate or is reinitialized, the ↓
┆8c┆┆83┆┆c8┆↓
RCLLC layer will detect the event and remove the connections in which ↓
the SAP took part. Each of the clients at the remote end of such a ↓
connection will be notified by means of a DISCONNECT.indication ↓
primitive.↲
↲
There is no guarantee that all service data units passed to the RCLLC ↓
layer for transmission will have been delivered before a connection is ↓
removed.↲
↲
When an RCLLC entity has removed (one end-point of) a connection and ↓
passed the indication to the client it will not establish a new ↓
connection to the same remote SAP until the client has acknowledged the ↓
removal of the connection by issuing a DISCONNECT.acknowledge primitive. ↓
This procedure is significant when a connection is removed because of a ↓
temporary malfunction or the reinitialization of a station. It allows ↓
the client to gracefully terminate any activity associated with the ↓
connection before it is reestablished.↲
↲
Details about the six primitives used in conjunction with client network ↓
service are given in the following subsections.↲
↲
↲
┆a1┆3.2.4.1 CONNECT.indication↲
↲
The primitive, which indicates that a connection has been established, ↓
is passed from the RCLLC entity to the client.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆is the local SAP address, i.e. the client network ↓
┆19┆┆93┆┄┄number.↲
rem_addr╞ is the station address of the remote SAP.↲
client_info╞ ┆84┆is the data unit passed to the RCLLC layer when the ↓
┆19┆┆93┆┄┄remote SAP was activated.↲
↲
After receiving the primitive the client may issue DATA.request ↓
primitives on the connection, and should expect DATA.indication ↓
primitives to arrive.↲
↲
↲
┆8c┆┆83┆┆e0┆↓
┆a1┆3.2.4.2 DISCONNECT.indication↲
↲
The primitive, which indicates that a connection has been removed, is ↓
passed from the RCLLC entity to the client.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆is the local SAP address, i.e. the client network ↓
┆19┆┆93┆┄┄number.↲
rem_addr╞ is the station address of the remote SAP.↲
reason╞ specifies why the connection was removed.↲
↲
The client should acknowledge receipt of the primitive by issuing a ↓
DISCONNECT.acknowledge primitive. A new connection to the same remote ↓
SAP will not be established until this has been done.↲
↲
↲
┆a1┆3.2.4.3 DISCONNECT.acknowledge↲
↲
The primitive, which acknowledges the removal of a connection, is passed ↓
from a client to the RCLLC entity.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆is the local SAP address, i.e. the client network ↓
┆19┆┆93┆┄┄number.↲
rem_addr╞ is the station address of the remote SAP.↲
↲
After receiving the primitive the RCLLC entity may establish a new ↓
connection to the same remote SAP.↲
↲
↲
┆a1┆3.2.4.4 DATA.request↲
↲
The primitive, which requests that an RCLLC service unit be transmitted ↓
on a connection, is passed from a client to the RCLLC entity.↲
↲
┆8c┆┆83┆┆bc┆↓
┆0e┆↓
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆is the local SAP address, i.e. the client network ↓
┆19┆┆93┆┄┄number.↲
┆0f┆↓
dest_addr╞ is the station address of the remote SAP.↲
l_sdu╞ is the service data unit to be transmitted.↲
↲
↲
┆a1┆3.2.4.5 DATA.confirm↲
↲
The primitive, which indicates that an RCLLC service data unit ↓
previously passed in a DATA.request primitive has been transmitted on a ↓
connection, is passed from the RCLLC entity to the requesting client.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆is the local SAP address, i.e. the client network ↓
┆19┆┆93┆┄┄number.↲
dest_addr╞ is the station address of the remote SAP.↲
result╞ ┆84┆indicates how the transmission went, e.g. 'no ↓
┆19┆┆93┆┄┄problems' or 'too many collisions'.↲
↲
The primitive may confirm that the data unit has been transmitted and ↓
acknowledged, but not that it has been delivered to and received by the ↓
remote client.↲
↲
↲
┆a1┆3.2.4.6 DATA.indication↲
↲
The primitive, which is used to deliver an RCLLC service unit received ↓
on a connection, is passed from the RCLLC entity to the client.↲
↲
┆a1┆Parameters┆e1┆:↲
↲
l_SAP_addr╞ ┆84┆is the local SAP address, i.e. the client network ↓
┆19┆┆93┆┄┄number.↲
dest_addr╞ is the station address of the remote SAP.↲
l_sdu╞ is the received service data unit.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆4. RCLLC PROCEDURES↲
↲
The description of RCLLC procedures falls in two parts: 1) the type 1 ↓
procedures which are in conformance with (ref. 1), and 2) the procedures ↓
for client network service which constitute a functional extension to ↓
the type 1 procedures.↲
↲
In general, an RCLLC protocol element may be a ┆a1┆command┆e1┆ protocol element ↓
or a ┆a1┆response┆e1┆ protocol element. As a protocol element is transmitted ↓
using the services of the MAC layer it may be addressed to one or ↓
several stations, using an individual, multicast, or broadcast station ↓
address. Within each addressed station an RCLLC protocol element is ↓
addressed either to the RCLLC entity as such or to a specific SAP.↲
↲
↲
┆a1┆4.1 Type 1 Procedures↲
↲
This section contains a general description of the type 1 procedures. ↓
Details not covered in the general description are given in conjunction ↓
with the individual protocol elements in section 5.↲
↲
↲
┆a1┆4.1.1 Unacknowledged Data Transfer↲
↲
This subsection applies to data transfer between active SAPs for which ↓
type 1 service has been requested.↲
↲
Unacknowledged connectionless data transfer as requested by the ↓
UDATA.request primitive is accomplished by transmission of a UI protocol ↓
element containing the service data unit passed as a parameter of the ↓
primitive. This may occur at any time while the source SAP is active.↲
↲
When a UI protocol element is correctly received, the service data unit ↓
which it contains is passed to the client by means of a UDATA.indication ↓
primitive. There is no associated acknowledgement or sequence checking. ↓
Notice that a UI protocol element which is found to be in error by the ↓
receiving MAC or RCLLC entity is simply discarded. Buffer shortage in ↓
the receiving RCLLC entity may also cause a UI protocol element to be ↓
discarded.↲
↲
↲
┆8c┆┆83┆┆ec┆↓
┆a1┆4.1.2 Loop-back Test Procedure↲
↲
An RCLLC entity will initiate the loop-back test procedure upon receipt ↓
of a TEST.request primitve from a client. It does so by transmitting a ↓
TEST command protocol element with the poll bit set to 1 and addressed ↓
as specified in the request. The information field of the TEST command ↓
will contain the specified test data unit. Notice that multi- or broad-↓
casting may be used to test several transmission paths using one command ↓
protocol element.↲
↲
For each TEST response protocol element which is subsequently received ↓
correctly, with or without an information field, the client is informed ↓
by means of a TEST.confirm primitive.↲
↲
An RCLLC entity will not transmit a TEST command protocol element, ↓
except when directed by a TEST.request primitive.↲
↲
When an RCLLC entity correctly receives a TEST command protocol element ↓
addressed to itself or to an active SAP, with the poll bit set to 1, it ↓
will respond by transmitting a TEST response protocol element addressed ↓
to the source RCLLC entity or SAP. The received information is copied to ↓
the response protocol element. If the information field could not be ↓
held in the receive buffer(s) of the RCLLC entity due to overlength, the ↓
response protocol element will contain an empty information field. In ↓
the case when the received TEST command protocol element is addressed to ↓
a SAP, the client will be informed by means of a TEST.indication ↓
primitive. Notice that the source station in this case will not be an ↓
RCLLC station.↲
↲
A TEST command protocol element received with poll bit set to 0 is ↓
discarded.↲
↲
↲
┆a1┆4.1.3 Station Identification Exchange↲
↲
Type 1 station identification exchange is not supported as part of the ↓
RCLLC service interface, and an RCLLC entity will not, therefore, ↓
transmit XID command protocol elements. It will, however, answer ↓
┆8c┆┆83┆┆c8┆↓
politely when an XID protocol element addressed to itself or to an ↓
active SAP is correctly received. Observe that the source station in ↓
this case will not be an RCLLC station.↲
↲
↲
┆a1┆4.2 Procedures for Client Network Service↲
↲
This section contains a general description of the procedures for client ↓
network service. Details not covered in the general description are ↓
given in conjunction with the individual protocol elements in section 5.↲
↲
Client networks are supervised by the RCLLC layer. The protocol element ↓
ACTIVE_SAP plays a central role in this respect. Whenever a SAP ↓
belonging to a client network is active the RCLLC entity serving the SAP ↓
will regularly transmit this protocol element to its peer entities using ↓
the multicast address for the client network. An RCLLC receiving the ↓
ACTIVE_SAP protocol element will discard it unless the included SAP ↓
mask matches the mask of the local SAP belonging to the same client ↓
network.↲
↲
This procedure serves to make a SAP known throughout the client network ↓
so that all desired connections to the SAP may be established. Notice ↓
that the SAP remains unknown to all stations where its mask does not ↓
match the local SAP mask.↲
↲
Moreover, the procedure allows RCLLC entities to supervise the liveness ↓
of all existing connections. When the ACTIVE_SAP protocol element fails ↓
to arrive from a SAP to which a connection exists, for a sufficiently ↓
long period of time, this will be taken to indicate that the SAP is no ↓
longer active, and the RCLLC entity will therefore remove its end of the ↓
connection.↲
↲
All protocol elements other than ACTIVE_SAP are transmitted using ↓
individual station address.↲
↲
The rigorous description of the procedures for establishment and ↓
supervision of connections which is given in the following is based on a ↓
state, two timers and a retransmission counter maintained by an RCLLC ↓
┆8c┆┆83┆┆c8┆↓
entity for each connection in which it takes part, i.e. for each remote ↓
SAP it knows. The following connection states exist: UNKNOWN, RESETTING, ↓
DATA, DISCONNECTING. The timers are:↲
↲
╞ - ┆84┆the acknowledgement timer which runs when an acknowledgement, i.e. ↓
┆19┆┆86┆┄┄a RACK or ACK protocol element is expected,↲
╞ - ┆84┆the SAP alive timer which runs whenever the remote SAP is known ↓
┆19┆┆86┆┄┄and is restarted each time an ACTIVE_SAP protocol element is ↓
┆19┆┆86┆┄┄received.↲
↲
In addition to the state, timers, and retransmission counter an RCLLC ↓
entity maintains for each connection two sequence counters for data ↓
units, N(S): the number of the data unit to transmit, and N(R): the ↓
number of the next data unit to be received.↲
↲
The following events may cause the state of a connection to change:↲
↲
PE_new_SAP╞ ┆84┆An ACTIVE_SAP protocol element is received from the ↓
┆19┆┆93┆┄┄remote SAP indicating it has become active, possibly ↓
┆19┆┆93┆┄┄by reinitialization, see subsection 5.2.1.↲
↲
PE_rack╞ ┆84┆A RACK or RESET protocol element is received from the ↓
┆19┆┆93┆┄┄remote SAP when RACK is expected.↲
↲
PE_reset╞ ┆84┆A RESET protocol element is received from the remote ↓
┆19┆┆93┆┄┄SAP, except when RACK is expected.↲
↲
give_up╞ ┆84┆The RCLLC entity gives up the connection when the ↓
┆19┆┆93┆┄┄retransmission counter is exhausted, or when the SAP ↓
┆19┆┆93┆┄┄alive timer runs out.↲
↲
SP_dack╞ ┆84┆An expected DISCONNECT.acknowledge service primitive ↓
┆19┆┆93┆┄┄is received from the client.↲
↲
An overview of the state changes caused by events and the associated ↓
actions, i.e. protocol elements and service primitives that are ↓
generated, is given in figure 1. Note that the figure and the ↓
description which follows apply to a single connection, in fact to each ↓
end-point separately.↲
↲
┆8c┆┆83┆┆e0┆↓
┆0e┆↓
╱04002d4e0c0006000000000201483100000000000000000000000000000000000000000000000000070d1a222a383f44474b555f69737dff04╱
╱04002d4e0c0006000000000301483160000000000000000000000000000000000000000000000000050a11191e464b555f69737dffffffff04╱
↓
╞ ╞ ╞ ┆a1┆╞ ╞ _↲
╞ ╞ ╞ !╞ ╞ !↲
╞ ╞ ╞ ! UNKNOWN╞ !<---------------------------!↲
╞ ╞ ╞ ┆a1┆!╞ ╞ !┆e1┆╞ ╞ ╞ ╞ !↲
╞ ╞ ╞ !╞ !╞ ╞ ╞ ╞ ╞ !↲
╞ ╞ PE_new_SAP╞ ! !╞ PE_reset╞ ╞ ╞ ╞ !↲
╞ ----------------------! !------------------------╞ ╞ !↲
╞ ! <RESET>╞ ╞ ╞ <RACK>╞ ╞ !╞ ╞ !↲
╞ ! <CONNECT_indication>╞ ╞ <CONNECT_indication>╞ !╞ ╞ !↲
╞ !╞ ╞ ╞ ╞ ╞ ╞ !╞ ╞ !↲
┆a1┆╞ v╞ ┆e1┆╞ ╞ ╞ ╞ ┆a1┆╞ v╞ ┆e1┆╞ !↲
!╞ ╞ !╞ PE_rack╞ ╞ !╞ ╞ !╞ !↲
! RESETTING╞ !----------------------------------------->! DATA !╞ !↲
┆a1┆!╞ ╞ !┆e1┆╞ ╞ ╞ ╞ ┆a1┆!╞ ╞ !┆e1┆╞ !↲
! !╞ PE_new_SAP╞ ╞ PE_new_SAP╞ ! ! !╞ ╞ !↲
! !----------------------> <----------------------! ! !╞ ╞ !↲
!╞ ╞ ╞ ╞ !╞ ╞ ! !╞ ╞ !↲
!╞ ╞ ╞ ╞ !╞ PE_reset╞ ! !╞ ╞ !↲
!╞ ╞ ╞ ╞ !<--------------------------! !╞ ╞ !↲
!╞ ╞ ╞ ╞ !╞ ╞ ╞ !╞ ╞ !↲
!╞ ╞ give_up╞ ╞ !╞ give_up╞ ╞ !╞ ╞ !↲
!---------------------------->!<------------------------------!╞ ╞ !↲
╞ ╞ ╞ ╞ !╞ ╞ ╞ ╞ ╞ !↲
╞ ╞ ╞ ╞ !<DISCONNECT_indication>╞ ╞ ╞ !↲
╞ ╞ ╞ ╞ !╞ ╞ ╞ ╞ ╞ !↲
╞ ╞ ╞ ┆a1┆╞ v╞ ┆e1┆╞ ╞ ╞ ╞ !↲
╞ ╞ ╞ !╞ ╞ ! SP_dack╞ ╞ ╞ ╞ !↲
╞ ╞ ╞ ! DISCONNECTING╞ !-----------------------------↲
╞ ╞ ╞ ┆a1┆!╞ ╞ !↲
╱04002d4e0c0006000000000301483100000000000000000000000000000000000000000000000000050f19232d37414b555f69737d8791ff04╱
╱04002d4e0c0006000000000201483100000000000000000000000000000000000000000000000000070d1a222a383f44474b555f69737dff04╱
↓
↲
Figure 1: State graph for a connection.↲
┆0f┆↓
↲
A general procedure applies to the transmission of protocol elements for ↓
which an acknowledgement is required in the form of a protocol element ↓
transmitted in the opposite direction, viz. RESET and DATA which are ↓
acknowledged by RACK and ACK, respectively. ┆a1┆Initiating┆e1┆ the ┆a1┆transmission┆e1┆ ↓
of one of these elements means: initializing the retransmission counter, ↓
starting the acknowledgement timer, and actually transmitting the ↓
protocol element. When the acknowledging protocol element arrives, the ↓
transmission is considered successfully completed, and the timer is ↓
stopped. If, on the other hand, the acknowledgement timer expires, the ↓
retransmission counter is decremented, and if it was exhausted, i.e. ↓
became zero, the connection is given up (give_up event). Otherwise, the ↓
timer is restarted and the protocol element retransmitted.↲
↲
There is never more than one outstanding protocol element requiring ↓
acknowledgement, i.e. transmission of a RESET or DATA protocol element ↓
┆8c┆┆83┆┆c0┆↓
is not initiated until transmission of the previous element is ↓
completed. For this reason a DATA.request primitive containing an RCLLC ↓
service data unit for transmission on a connection may be accepted while ↓
an unacknowledged protocol element is outstanding, but it will then be ↓
queued (by the RCLLC entity) for transmission rather than processed ↓
immediately.↲
↲
The remaining part of this section contains a discussion of the meaning ↓
of each state of a connection (end-point) and the procedures followed by ↓
an RCLLC entity in each state.↲
↲
UNKNOWN↲
↲
The RCLLC entity has no knowledge of the remote SAP, but is ready to ↓
establish a connection. No service primitives are accepted and all ↓
protocol elements except ACTIVE_SAP and RESET are discarded.↲
↲
A received ACTIVE_SAP protocol element (with matching SAP mask) consti┄↓
tutes a PE_new_SAP event. It causes the RCLLC entity to establish a ↓
connection to the remote SAP by starting the SAP alive timer, initiating ↓
the transmission of a RESET protocol element, resetting the sequence ↓
counters, passing a CONNECT.indication primitive to the client, and ↓
changing the connection state to RESETTING.↲
↲
A received RESET protocol element constitutes a PE_reset event indi┄↓
cating that the local SAP has become known to the remote RCLLC entity ↓
and caused it to establish a connection. The local RCLLC entity will ↓
establish its end of the connection by starting the SAP alive timer, ↓
transmitting a RACK protocol element to acknowledge RESET, resetting the ↓
sequence counters, passing a CONNECT.indication primitive to the client, ↓
and changing the connection state to DATA.↲
↲
RESETTING↲
↲
The RCLLC entity has established the connection by initiating the trans┄↓
mission of a RESET protocol element. The state is used to wait for the ↓
acknowledging RACK protocol element after which data may be transmitted ↓
in both directions.↲
↲
┆8c┆┆83┆┆d4┆↓
DATA.request primitives are accepted (queued). DISCONNECT.acknowledge ↓
primitives are discarded.↲
↲
A received RESET or RACK protocol element constitutes a PE_rack event ↓
and causes the RCLLC entity to change the connection state to DATA. ↓
RESET, which may occur if RESET protocol elements are transmitted in ↓
both directions simultaneously, is answered with RACK.↲
↲
Received DATA or ACK protocol elements are discarded.↲
↲
If a PE_new_SAP event occurs (cf. subsection 5.2.1), or if the ↓
connection is given up, either because the SAP alive timer expires or ↓
because the RESET protocol element is retransmitted to exhaustion, the ↓
RCLLC entity will pass a DISCONNECT.indication primitive to the client ↓
and change the connection state to DISCONNECTING.↲
↲
DATA↲
↲
The connection has been completely established through the exchange of ↓
RESET and RACK protocol elements. In this state RCLLC service data units ↓
are transferred between the two SAPs through the exchange of DATA and ↓
ACK protocol elements between the RCLLC entities.↲
↲
Each DATA.request primitive received from the client causes initiation ↓
of the transmission of a DATA protocol element containing the service ↓
data unit passed as a parameter of the primitive. The sequence number of ↓
the protocol element is set equal to the value of N(S), and subsequently ↓
N(S) is incremented modulo 2. Initiation of the transmission of the ↓
protocol element takes place: either when an ACK or RACK protocol ↓
element is received marking the successful completion of a previous ↓
transmission provided a non-empty queue of service data units are ↓
awaiting transmission; or immediately upon receipt of the DATA.request ↓
primitive if there is no outstanding protocol element awaiting ↓
acknowledgement.↲
↲
When a DATA protocol element is received, its sequence number is ↓
compared to the value of N(R). If they are equal the received service ↓
data unit is passed to the client by means of a DATA.indication primi┄↓
┆8c┆┆83┆┆c8┆↓
tive, and N(R) is incremented modulo 2. Otherwise, the service data unit ↓
is discarded. In both cases an ACK protocol element with sequence number ↓
equal to that of the DATA protocol element is transmitted to the remote ↓
SAP in order to acknowledge receipt.↲
↲
If a RACK protocol element or a DISCONNECT.acknowledge service primitive ↲
is received, it is discarded.↲
↲
If a PE_new_SAP event occurs (cf. subsection 5.2.1), if a RESET protocol ↓
element is received, or if the connection is given up, either because ↓
the SAP alive timer expires or because a DATA protocol element is re┄↓
transmitted to exhaustion, the RCLLC entity will pass a ↓
DISCONNECT.indication primitive to the client and change the connection ↓
state to DISCONNECTING.↲
↲
DISCONNECTING↲
↲
The connection has been disconnected as seen from the point of view of ↓
the RCLLC layer. This state allows the client to decide when it will ↓
accept the connection to be reestablished.↲
↲
All received protocol elements and service primitives are discarded ↓
except the DISCONNECT.acknowledge primitve. When this primitive is ↓
received the connection state is changed to UNKNOWN.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆5. RCLLC PROTOCOL ELEMENTS↲
↲
All RCLLC protocol elements conform to the syntax for LLC type 1 ↓
protocol elements ("protocol data units"). This is achieved by defining ↓
the formats of all the protocol elements used in the procedures oriented ↓
toward client network service to be instances of type 1 UI (Unnumbered ↓
Information) commands.↲
↲
The following conventions apply to the figures in this section: the ↓
octets of a protocol element are shown in the order they are transmitted ↓
downward on the page, and the bits within an octet similarly from left ↓
to right. The least significant bit position within an octet, the ↓
contents of which is transmitted first, is numbered 0, and so forth.↲
↲
The general format for type 1 protocol elements consists of a three-↓
octet link control header followed by an information field:↲
↲
╱04002d4e0c00060000000002014831000000000000000000000000000000000000000000000000000b0f2f37414b555f69737d8791ffffff04╱
╱04002d4e0c0006000000000301483100000000000000000000000000000000000000000000000000050f19232d37414b555f69737d8791ff04╱
↓
bit no.╞ ┆a1┆ 0 1 2 3 4 5 6 7 ↲
octet no. 0╞ ┆a1┆! 0 ! 0 ! DSAP╞ !↲
╞ 1╞ ┆a1┆!C/R! 0 ! SSAP╞ !↲
╞ 2╞ ┆a1┆! Control╞ !↲
╞ 3╞ !╞ !↲
╞ ╞ ! Type 1 Information╞ !↲
╱04002d4e0c00060000000003014831000000000000000000000000000000000000000000000000000b0f2f37414b555f69737d8791ffffff04╱
╱04002d4e0c00060000000002014831000000000000000000000000000000000000000000000000000b0f2f37414b555f69737d8791ffffff04╱
↓
╞ ╞ ┆a1┆!╞ !↲
↲
The DSAP field contains the local SAP address of the destination SAP and ↓
the SSAP field the local SAP address of the source SAP.↲
↲
If the DSAP field contains 0 (all bits 0) the protocol element is ↓
interpreted as addressed to the destination RCLLC (or other LLC type 1) ↓
entity rather than to a client.↲
↲
If the DSAP field does not contain all 0 bits, its contents taken as a ↓
binary number in the range 1..63 is interpreted as the address of an ↓
individual SAP.↲
↲
A C/R bit with value 0 indicates a command protocol element, and one ↓
with value 1 a response protocol element. The UI protocol element, and ↓
thus all protocol elements for client network service can only be ↓
transmitted as commands, i.e. with the C/R bit set to 0.↲
↲
┆8c┆┆83┆┆d4┆↓
Bit 0 of octet 0 and bit 1 of octet 1 must always be 0.↲
↲
If the SSAP field contains 0 (all bits 0), the protocol element is ↓
interpreted as originating from the source RCLLC (or other LLC type 1) ↓
entity rather than from a client. Otherwise, the contents of the SSAP ↓
field is interpreted as a binary number in the range 1..63.↲
↲
Bit 4 of octet 2 (the Control field) is the Poll/Final bit. When this ↓
bit is set to 1 (Poll) in a command, a response is requested. The ↓
response should contain the same coding of the Control field; i.e., bit ↓
4 (Final) should also be set in the response. The Poll bit must not be ↓
set in a UI protocol element; thus this bit is 0 in all protocol ↓
elements for client network service.↲
↲
The SSAP field of a response protocol element always contains the same ↓
value as the DSAP field of the command protocol element to which it ↓
corresponds, and vice versa.↲
↲
The remaining bits of the Control field specify the type of protocol ↓
element in question, viz.:↲
↲
11000000╞ ╞ UI, Unnumbered Information↲
1111X101╞ ╞ XID, eXchange IDentification↲
1100X111╞ ╞ TEST↲
↲
The use of the Type 1 Information field depends on the type of protocol ↓
element, and is described for each element type in section 5.1.↲
↲
The protocol elements for client network service are UI commands ↓
addressed to an individual SAP with three extra octets of RCLLC header ↓
in addition to the LLC type 1 header. Source and destination SAPs have ↓
the same local address which is equal to the client network number, ↓
Netno. The format is as shown below:↲
↲
┆8c┆┆83┆┆98┆↓
┆0e┆↓
╱04002d4e0c00060000000002014831000000000000000000000000000000000000000000000000000b0f292f37414b555f69737d8791ffff04╱
╱04002d4e0c00060000000003014831000000000000000000000000000000000000000000000000000b0f2f37414b555f69737d8791ffffff04╱
↓
bit no.╞ ┆a1┆ 0 1 2 3 4 5 6 7 ↲
octet no. 0╞ ┆a1┆! 0 0 ! Netno╞ !↲
╞ 1╞ ┆a1┆! 0 0 ! Netno╞ !┆e1┆ type 1↲
╞ 2╞ ┆a1┆! 1 1 0 0 0 0 0 0╞ !┆e1┆ header RCLLC↲
╞ 3╞ ┆a1┆! Function╞ !┆e1┆ header↲
╞ 4╞ ┆a1┆! Param 0╞ !↲
╞ 5╞ ┆a1┆! Param 1╞ !↲
╞ 6╞ !╞ !↲
╞ ╞ ! Information╞ !↲
╱04002d4e0c00060000000003014831000000000000000000000000000000000000000000000000000b0f292f37414b555f69737d8791ffff04╱
╱04002d4e0c00060000000002014831000000000000000000000000000000000000000000000000000b0f292f37414b555f69737d8791ffff04╱
↓
╞ ╞ ┆a1┆!╞ !↲
┆0f┆↓
↲
The value in the Function field specifies the type of protocol element, ↓
viz.:↲
↲
00000000 (binary 0) ACTIVE_SAP↲
10000000 (binary 1) RESET↲
01000000 (binary 2) RACK↲
11000000 (binary 3) DATA↲
00100000 (binary 4) ACK↲
↲
The use of the Param 0 and 1 fields and of the Information field depends ↓
on the type of protocol element, and is described for each element type ↓
in section 5.2.↲
↲
↲
┆a1┆5.1 Type 1 Protocol Elements↲
↲
This section specifies the encoding of the Type 1 Information field of ↓
protocol elements used in conjunction with type 1 procedures.↲
↲
↲
┆a1┆5.1.1 UI (Unnumbered Information)↲
↲
The UI protocol element may only be transmitted as a command, i.e. the ↓
C/R bit must be 1.↲
↲
When the protocol element is used for type 1 service the Type 1 ↓
Information field is used to hold an RCLLC service data unit.↲
↲
┆8c┆┆83┆┆b0┆↓
┆0e┆↓
┆a1┆5.1.2 XID (eXchange IDentification)↲
↲
The Type 1 Information field in a received XID command is ignored. In an ↓
XID response protocol element transmitted by an RCLLC entity three ↓
octets, numbers 6 through 8, are encoded as follows:↲
┆0f┆↓
↲
╱04002d4e0c00060000000002014831000000000000000000000000000000000000000000000000000b0f28414b555f69737d8791ffffffff04╱
╱04002d4e0c00060000000003014831000000000000000000000000000000000000000000000000000b0f292f37414b555f69737d8791ffff04╱
↓
bit no.╞ ┆a1┆ 0 1 2 3 4 5 6 7 ↲
octet no. 6╞ ┆a1┆! 1 0 0 0 0 0 0 1╞ !↲
╞ 7╞ ┆a1┆! 1 0 0 0 0 0 0 0╞ !┆e1┆↲
╱04002d4e0c00060000000003014831000000000000000000000000000000000000000000000000000b0f282f37414b555f69737d8791ffff04╱
╱04002d4e0c00060000000002014831000000000000000000000000000000000000000000000000000b0f28414b555f69737d8791ffffffff04╱
↓
╞ 8╞ ┆a1┆! 0 0 0 0 0 0 0 0╞ !↲
↲
↲
┆a1┆5.1.3 TEST↲
↲
The Type 1 Information field is used to hold a test data unit. The ↓
associated procedure is described in subsection 4.1.2.↲
↲
↲
┆a1┆5.2 Protocol Elements for Client Network Service↲
↲
In order to facilitate speedy access to status information associated ↓
with connections, each RCLLC entity will assign to each connection an ↓
index in the range 0..255. When a connection is established the assigned ↓
indices are exchanged between the two RCLLC entities. Subsequent DATA ↓
and ACK protocol elements each contain the index assigned to the ↓
connection by the receiver of the element.↲
↲
↲
┆a1┆5.2.1 ACTIVE_SAP↲
↲
An RCLLC entity transmits this protocol element periodically for each ↓
active SAP it serves which belongs to a client network. It is ↓
transmitted using the multicast address for the client network in ↓
question so that all relevant RCLLC entities will receive it. The ↓
frequency with which the protocol element is transmitted depends on the ↓
implementation.↲
↲
The first word of the Information field contains the SAP mask of the ↓
active SAP. Unless the mask matches that of the local SAP at the ↓
receiving RCLLC entity the protocol element is discarded.↲
↲
┆8c┆┆83┆┆e0┆↓
The Param 1 field contains a sequence number in the range 0..254. The ↓
first 255 ACTIVE_SAP protocol elements transmitted after activation of a ↓
SAP will have sequence numbers 0, 1, 2,.. 254. In all subsequent ↓
ACTIVE_SAP protocol elements the sequence number will also be 254. This ↓
procedure allows the receiving RCLLC entity to detect when a SAP is ↓
deactivated and swiftly reactivated, possibly because of station re┄↓
initialization.↲
↲
When an ACTIVE_SAP protocol element is received from a previously ↓
unknown SAP a PE_new_SAP event is generated (cf. section 4.2). The same ↓
is the case if the sequence number is less than the sequence number ↓
found in the last received ACTIVE_SAP or RESET protocol element from the ↓
same SAP. However, when the sequence number are equal or ascending, the ↓
protocol element is only taken to indicate that the SAP is still active. ↓
In the latter case the SAP alive timer is restarted.↲
↲
The Information field from the third byte onwards contains the ↓
client_info passed from the client when the SAP was activated.↲
↲
↲
┆a1┆5.2.2 RESET↲
↲
This protocol element is transmitted in conjunction with establishment ↓
of a connection.↲
↲
The Param 0 field contains the index assigned to the connection by the ↓
sending RCLLC entity.↲
↲
The Param 1 field contains the sequence number to be included in the ↓
next ACTIVE_SAP protocol element to be transmitted from the sender.↲
↲
The Information field contains the client_info passed from the client ↓
when the SAP was activated.↲
↲
↲
┆8c┆┆83┆┆a4┆↓
┆0e┆↓
┆a1┆5.2.3 RACK↲
↲
This protocol element is transmitted to acknowledge receipt of a RESET ↓
protocol element in conjunction with establishment of a connection.↲
┆0f┆↓
↲
The Param 0 field contains the index assigned to the connection by the ↓
sending RCLLC entity.↲
↲
The Param 1 field contains the index assigned to the connection by the ↓
receiver as indicated in the RESET protocol element being acknowledged.↲
↲
The Information field is empty.↲
↲
↲
┆a1┆5┆a1┆.2.4 DATA↲
↲
This protocol element is transmitted to carry an RCLLC service data unit ↓
from the source SAP to the destination SAP.↲
↲
The Param 0 field contains the sequence number of the element, cf. ↓
section 4.2. The sequence number, which can only be 0 or 1 is placed in ↓
bit 0. The remaining bits are all 0.↲
↲
The Param 1 field contains the index assigned to the connection at the ↓
destination RCLLC entity.↲
↲
The Information field contains the RCLLC service data unit.↲
↲
↲
┆a1┆5.3.5 ACK↲
↲
This protocol element is transmitted to acknowledge receipt of a DATA ↓
protocol element on a connection.↲
↲
The Param 0 field contains the sequence number of the element being ↓
acknowledged.↲
↲
┆8c┆┆83┆┆bc┆↓
The Param 1 field contains the index assigned to the connection at the ↓
destination RCLLC entity, i.e. the sender of the DATA element.↲
↲
The Information field is empty.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆A. REFERENCES↲
↲
(ref.1)╞ ISO/DP 8802/2 (TC 97/SC 6 N2925)↲
╞ Local Area Networks - Logical Link Control - Draft E↲
↲
(ref.2)╞ ISO/DIS 7498↲
╞ Data Processing - Open Systems Interconnection↲
╞ Basic Reference Model↲
╞ Feb. 4, 1982↲
↲
(ref.3)╞ RCSL No. 42-i1982:↲
╞ Distributed System Architecture, Report↲
↲
(ref.4)╞ RCSL No. 42-i1983:↲
╞ DSA Inter Module Communication,↲
╞ Functional Description↲
↲
(ref.5)╞ DR Soft/Net, Network Operating System,↲
╞ System Guide↲
╞ Digital Research, 1984.↲
┆1a┆┆1a┆╞ System G