5i' FASCICLE VI.10 Recommendations Q.920 and Q.921 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 (DSS1), DATA LINK LAYER Blanc MONTAGE: PAGE 2 = PAGE BLANCHE DATA LINK LAYER Recommendation Q.920 ISDN USER-NETWORK INTERFACE DATA LINK LAYER - GENERAL ASPECTS 1 General This Recommendation describes in general terms the Link Access Procedure on the D-channel, LAPD. The application of this protocol to other channel types is for further study. Details are provided in Recommendation Q.921(I.441) [1]. The purpose of LAPD is to convey information between layer 3 entities across the ISDN user-network interface using the D-channel. The definition of LAPD takes into consideration the principles and terminology of: - Recommendations X.200 [2] and X.210 [3] - the reference model and layer service conventions for Open Systems Interconnection (OSI); - Recommendation X.25 [4] - LAPB user-network interface for packet mode terminals; and - ISO 3309 [5] and ISO 4335 [6] - High-level Data Link Control (HDLC) standards for frame structure and elements of procedures. LAPD is a protocol that operates at the data link layer of the OSI architecture. The relationship between the data link layer and other protocol layers is defined in Recommendation I.320 [7]. Note 1 - The physical layer is currently defined in Recommendations I.430 [8] and I.431 [9] and layer 3 is defined in Recommendations Q.930(I.450) [10], Q.931(I.451) [11], and X.25 [4]. References should be made to these Recommendations for the complete definition of the procotols and procedures across the ISDN user-network interface. Note 2 - The term "data link layer" is used in the main text of this Recommendation. However, mainly in figures and tables, the terms "layer 2" and "L2" are used as abbreviations. Furthermore, in accordance with Recommendations Q.930(I.450) [10] and Q.931(I.451) [11], the term "layer 3" is used to indicate the layer above the data link layer. LAPD is independent of transmission bit rate. It requires a duplex, bit transparent D-channel. The characteristics of the D-channel are defined in Recommendation I.412 [12]. S 2 below describes basic concepts used in this Recommendation and Recommendation Q.921. S 3 gives an overview description of LAPD functions and pro- cedures. S 4 summarizes the services that the data link layer provides to layer 3 and the services that the data link layer requires from the physical layer. S 5 provides an overview of the data link layer structure. 2 Concepts and terminology The basic structuring technique in the OSI reference model is layering application processes is viewed as being logically parti- tioned into an ordered set of layers represented in a vertical sequence as shown in Figure 1/Q.920. A data link layer Service Access Point (SAP) is the point at which the data link layer provides services to layer 3. Associated with each data link layer SAP is one or more data link connection endpoint(s). See Figure 2/Q.920. A data link connection endpoint is identified by a data link connection endpoint identifier as seen from layer 3 and by a Data Link Connection Identifier (DLCI) as seen from the data link layer. Entities exist in each layer. Entities in the same layer, but in different systems which must exchange information to achieve a common objective are called " peer entities ". Entities in adjacent layers interact through their common boundary. The services pro- vided by the data link layer are the combination of the services and functions provided by both the data link layer and the physical layer Figure 1/Q.920, p. Figure 2/Q.920, p. Cooperation between data link layer entities is governed by a peer-to-peer protocol specific to the layer. In order for informa- tion to be exchanged between two or more layer 3 entities, an asso- ciation must be established between the layer 3 entities in the data link layer using a data link layer protocol. This association is called a data link connection or more SAPs (see Figure 3/Q.920). Figure 3/Q.920, p. Data link layer message units are conveyed between data link layer entities by means of a physical connection. Layer 3 requests services from the data link layer via service primitives layer and the physical layer. The primitives represent, in an abstract way, the logical exchange of information and control between the data link layer and adjacent layers. They do not specify or constrain implementation. The primitives that are exchanged between the data link layer and adjacent layers are of the following four types (see also Figure 4/Q.920): a) REQUEST; b) INDICATION; c) RESPONSE; and d) CONFIRM. Figure 4/Q.920, p. The REQUEST primitive type is used when a higher layer is requesting a service from the next lower layer. The INDICATION primitive type is used by a layer providing a service to notify the next higher layer of any specific activity which is service related. The INDICATION primitive may be the result of an activity of the lower layer related to the primitive type REQUEST at the peer entity. The RESPONSE primitive type is used by a layer to acknowledge receipt, from a lower layer, of the primitive type INDICATION. The CONFIRM primitive type is used by the layer providing the requested service to confirm that the activity has been completed. Layer-to-layer interactions are specified in Recommendation Q.921. Information is transferred, in various types of message units, between peer entities and between entities in adjacent layers that are attached to a specific SAP. The message units are of two types: - message units of a peer-to-peer protocol; and - message units that contain layer-to-layer infor- mation concerning status and specialized service requests. The message units of the layer 3 peer-to-peer protocol are carried by the data link connection. The message units containing layer-to-layer information concerning status and specialized ser- vice requests are never conveyed over a data link connection or a physical connection. This Recommendation specifies (see also Figure 5/Q.920): a) the peer-to-peer protocol for the transfer of information and control between any pair of data link layer service access points; and b) the interactions between the data link layer and layer 3, and between the data link layer and the physical layer. Figure 5/Q.920, p. 3 Overview description of LAPD functions and procedures 3.1 General The purpose of LAPD is to convey information between layer 3 entities across the ISDN user-network interface using the D-channel. Specifically LAPD will support: - multiple terminal installations at the user-network interface; - multiple layer 3 entities. All data link layer messages are transmitted in frames which are delimited by flags. (A flag is a unique bit pattern.) The frame structure is defined in Recommendation Q.921(I.441). LAPD includes functions for: a) the provision of one or more data link connec- tions on a D-channel. Discrimination between the data link connec- tions is by means of a data link connection identifier (DLCI) con- tained in each frame; b) frame delimiting, alignment and transparency, allowing recognition of a sequence of bits transmitted over a D-channel as a frame; c) sequence control, to maintain the sequential order of frames across a data link connection; d) detection of transmission, format and opera- tional errors on a data link connection; e) recovery from detected transmission, format, and operational errors; f ) notification to the management entity of unre- coverable errors; and g) flow control. Data link layer functions provide the means for information transfer between multiple combinations of data link connection end- points. The information transfer may be via point-to-point data link connections or via broadcast data link connections. In the case of point-to-point information transfer, a frame is directed to a single endpoint, while in the case of broadcast information transfer, a frame is directed to one or more endpoints. Figure 6/Q.920 shows three examples of point-to-point informa- tion transfer. Figure 7/Q.920 shows an example of broadcast infor- mation transfer. Two types of operation of the data link layer are defined for layer 3 information transfer: unacknowledged and acknowledged. They may coexist on a single D-channel. 3.2 Unacknowledged operation With this type of operation layer 3 information is transmitted in Unnumbered Information (UI) frames. At the data link layer the UI frames are not acknowledged. Even if transmission and format errors are detected, no error recovery mechanism is defined. Flow control mechanisms are not defined. Unacknowledged operation is applicable for point-to-point and broadcast information transfer; that is, a UI frame may be sent to a specific endpoint or broadcast to multiple endpoints associated with a specific Service Access Point Identifier (SAPI). 3.3 Acknowledged operation With this type of operation, layer 3 information is transmit- ted in frames that are acknowledged at the data link layer. Error recovery procedures based on retransmission of unack- nowledged frames are specified. In the case of errors which cannot be corrected by the data link layer, a report to the management entity is made. Flow control procedures are also defined. Acknowledged operation is applicable for point-to-point infor- mation transfer. One form of acknowledged information transfer is defined, mul- tiple frame operation. Figure 6/Q.920, p. Figure 7/Q.920, p. Layer 3 information is sent in numbered Information (I) frames. A number of I frames may be outstanding at the same time. Multiple frame operation is initiated by a multiple frame estab- lishment procedure using a Set Asynchronous Balanced Mode Extended (SABME) command. 3.4 Establishment of information transfer modes 3.4.1 Data link connection identification A data link connection is identified by a Data Link Connection Identifier (DLCI) carried in the address field of each frame. The data link connection identifier is associated with a con- nection endpoint identifier at the two ends of the data link con- nection (see Figure 8/Q.920). The connection endpoint identifier is used to identify message units passed between the data link layer and layer 3. It consists of the SAPI and the Connection Endpoint Suffix (CES). The DLCI consists of two elements: the SAPI and the Terminal Endpoint Identifier (TEI). The SAPI is used to identify the service access point on the network side or the user side of the user-network interface. The TEI is used to identify a specific connection endpoint within a service access point. The TEI is assigned by the network, if the user equipment is of the automatic TEI assignment category or it is entered into the user equipment, for example, by the user or the manufacturer, if the user equipment is of the nonautomatic TEI assignment category (see S 3.4.3). The DLCI is a pure data link layer concept. It is used inter- nally by the data link layer entity and is not known by the layer 3 entity or management entity. In these latter entities, the concept of Connection Endpoint Identifier (CEI) will be used instead. The CEI is composed of the SAPI information and a reference value named CES. The CES is a value selected by the layer 3 or management entity to address the data link layer entity. When the relevant TEI is known by this entity, it will internally associate the DLCI to the CEI. The layer 3 and management entities will use this CEI to address its peer entity. Figure 8/Q.920, p. 3.4.2 Data link states A point-to-point data link entity may be in one of three basic states: a) TEI-unassigned state. In this state a TEI has not been assigned. No layer 3 information transfer is possible; or b) TEI-assigned state. In this state a TEI has been assigned by means of the TEI assignment procedure. Unacknowledged information transfer is possible; or c) multi-frame-established state. This state is established by means of a multiple frame establishment procedure. Acknowledged and unacknowledged information transfer are possible. Note - For the detailed description of procedures in Recommendation Q.921(I.441), an expansion of the basic set of states listed above is required. A broadcast data link entity is always in an information transfer state capable of only unacknowledged information transfer (that is, TEI-assigned state). 3.4.3 TEI administration The purpose of the TEI assignment procedure is to allow a user equipment to obtain a TEI value that the data link layer entities within the user equipment will use in subsequent communications over the data link connections. The assigned TEI value is typically common to all SAPs (if more than one) in a user equipment. The procedure is conceptually located in the management entity. When a TEI has been assigned, the user equipment establishes an association between the TEI and a CES in each SAP (that is, the DLCI is associated with a CEI). In the network, the corresponding association is made upon reception of the first frame containing the assigned TEI, or at the time of TEI assignment. At that point in time, a data link layer peer-to-peer associa- tion has been formed. The association between the DLCI and CEI will be removed by the TEI removal procedures on request from the management entity when recognizing that the TEI value is no longer valid. When in the TEI-assigned state or the multiple-frame-established state, the TEI check procedure may be used by the network to check the status of a TEI (for example, to determine if a user equipment has been disconnected from an instal- lation). Optionally, the user equipment may request the network to initiate the TEI check procedure. Examples of criteria for initiation of the TEI assignment pro- cedure, the TEI check procedure, and the TEI removal procedures are described in Recommendation Q.921(I.441). Note - This section is not intended to provide a complete specification of possible criteria for establishing and removing an association between the DLCI and CEI. 3.4.4 Establishment of multiple frame operation Before point-to-point acknowledged information transfer can start, an exchange of a SABME frame and an Unnumbered Acknowledge- ment (UA) frame must take place. The multiple frame establishment procedure is specified in detail in Recommendation Q.921. 4 Service characteristics 4.1 General The data link layer provides services to layer 3 and to the layer 2 management entity and utilizes the services provided by the physical layer and layer management. A formal description of the data link layer service provided to layer 3 and layer management is given in S 4.2 and S 4.3, respectively. The layer management ser- vice provided to the data link layer is given in S 4.4. Note - Communication between different layers in the OSI reference model makes use of primitives which are passed across the layer boundaries. The data link layer primitives defined in this Recommendation represent, in an abstract way, the logical exchange of information and control between the data link layer and adjacent layers. They do not specify nor constrain implementations. 4.2 Services provided to layer 3 The specification of the interactions with layer 3, (primi- tives) provides a description of the services that the data link layer, plus the physical layer, offer to layer 3, as viewed from layer 3. Two forms of information transfer service are associated with layer 3. The first is based on unacknow ledged information transfer at the data link layer while the second service is based on ack- nowledged information transfer at the data link layer. Layer 3 message units are handled according to their respec- tive layer 2 priority (see S 5.2). 4.2.1 Unacknowledged information transfer service Note - In this case the information transfer is not ack- nowledged at the data link layer. Acknowledgement procedures may be provided at higher layers. The information transfer is via broadcast or point-to-point data link connections. The characteristics of the unacknowledged information transfer service are summarized in the following: a) provision of a data link connection between layer 3 entities for unacknowledged information transfer of layer 3 message units; b) identification of data link connection end- points; and c) no verification of message arrival within the peer data link layer entity. The primitives associated with the unacknowledged information transfer service are: DL-UNIT DATA-REQUEST/INDICATION The DL-UNIT DATA-REQUEST primitive is used to request that a message unit be sent using the procedures for unacknowledged infor- mation transfer service. The DL-UNIT DATA-INDICATION primitive indicates the arrival of a message unit received by means of an unacknowledged information transfer service. 4.2.2 Acknowledged information transfer service One mode of operation is defined, multiple frame. The characteristics of the acknowledged information transfer service are summarized in the following: a) provision of a data link connection between layer 3 entities for acknowledged information transfer of layer 3 message units; b) identification of data link connection end- points; c) sequence integrity of data link layer message units in the absence of malfunctions; d) notification to the peer entity in the case of errors, for example, loss of sequence; e) notification to the management entity of unre- coverable errors detected by the data link layer; and f ) flow control. The primitives associated with the acknowledged information transfer services are: i) Data transfer DL-DATA-REQUEST/INDICATION The DL-DATA-REQUEST primitive is used to request that a message unit be sent using the procedures for the acknowledged information transfer service. The DL-DATA-INDICATION primitive indicates the arrival of a message unit received by means of the acknowledged information transfer service. ii) Establishment of multiple frame operation DL-ESTABLISH-REQUEST/INDICATION/CONFIRM These primitives are used, respectively, to request, indi- cate and confirm the establishment of multiple frame operation between two service access points. iii) Termination of multiple frame operation DL-RELEASE-REQUEST/INDICATION/CONFIRM These primitives are used, respectively, to request, indi- cate and confirm an attempt to terminate multiple frame operation between two service access points. 4.3 Services provided to layer management Only the unacknowledged information transfer service is pro- vided to layer management in order that the data link layer manage- ment can communicate with its peer layer management. Note - In this case the information transfer is not ack- nowledged at the data link layer. Acknowledgement procedures may be provided by layer management. The information transfer is via broadcast connections, but in principle information transfer can also be via point-to-point con- nections [no application for data transfer via point-to-point con- nections has been identified or included in Recommendation Q.921(I.441)]. The characteristics of the unacknowledged information transfer service are summarized in the following: a) provision of a data link connection between layer management entities for unacknowledged information transfer of data units; b) identification of data link connection end- points; and c) no verification of message arrival within the peer data link layer entity. The primitives associated with the unacknowledged information transfer service provided for layer management are: MDL-UNIT DATA-REQUEST/INDICATION The MDL-UNIT DATA-REQUEST primitive is used to request that a message unit be sent using the procedure for unacknowledged information transfer service for layer management. The MDL-UNIT DATA-INDICATION primitive indicates the arrival of a message unit received by means of the unacknowledged information transfer ser- vice to layer management. 4.4 Administrative services The characteristics of the administrative services currently recognized are summarized in the following: a) assignment, checking, and removal of TEI values; and b) data link connection parameter passing (an optional service performed on a per connection basis). These services are considered to be conceptually provided by layer management either on the user side or the network side. The method of describing these administrative functions uses service primitives. The primitives associated with these services are: i) Assignment of TEI value MDL-ASSIGN-REQUEST/INDICATION The MDL-ASSIGN-INDICATION primitive is used to indicate to layer management the need for a TEI value. The MDL-ASSIGN-REQUEST primitive is used to pass the TEI value from layer management to the data link layer in order that the user data link layer entities can begin to communicate with the network data link layer entities. ii) Removal of TEI value MDL-REMOVE-REQUEST This primitive is used to convey a layer management func- tion request for removal of a TEI value that has been previously assigned via the MDL-ASSIGN primitives. iii) Notification of error MDL-ERROR-INDICATION/RESPONSE These primitives are used to report error situations between layer management and the data link layer entities. 4.5 Model of the data link service 4.5.1 General The ability of the data link layer to execute a service request by layer 3 depends on the internal state of the data link layer. For the layer 3 entity, the internal state of the data link layer is represented by the state of that data link connection end- point within a data link service access point which is used by this layer 3 entity to invoke a service. Consequently, the data link service may be defined by means of data link connection endpoint states, whereby the capabilities pro- vided by the data link layer and the service primitives may be related to these states. In order to allow a data link service user to invoke a service by making use of primitives, the DL-primitives defined in Recommendation Q.921(I.441) have to be related to: point-to-point data link connections (acknowledged or unacknowledged transfer of information) and/or broadcast data link connections (unacknow ledged transfer of information) (see Table 1/Q.920). An unconfirmed service is defined as a service which does not result in an explicit confirmation. A confirmed service is defined as a service which results in an explicit confirmation from the service-provider. There is not necessarily any relationship to a response from the peer service-user. H.T. [T1.920] TABLE 1/Q.920 Applicability of DL-Primitives to information transfer modes ______________________________________________________________________________ { { { ACKNOWLEDGED UNACKNOWLEDGED ESTABLISH CONFIRMED SERVICE ______________________________________________________________________________ RELEASE CONFIRMED SERVICE ______________________________________________________________________________ DATA UNCONFIRMED SERVICE ______________________________________________________________________________ UNIT DATA UNCONFIRMED SERVICE UNCONFIRMED SERVICE ______________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table [T1.920], p. 4.5.2 Data link layer representation as seen by layer 3 4.5.2.1 Data link connection endpoint states The states of a data link connection endpoint may be derived from the internal states of the data link layer entity supporting this type of a data link connection. 4.5.2.2 Broadcast data link layer connection services A broadcast data link connection provides an unacknowledged information transfer service. The broadcast data link connection endpoint is always in the information transfer state. 4.5.2.3 Point-to-point data link connection endpoint ser- vices A point-to-point data link connection provides both an unack- nowledged and acknowledged information transfer service. Within each data link service access point, one or more than one data link connection endpoint may be present, each identified by a CES. The acknowledged information transfer service, in addition, implies the presence of the link establishment, link re-establishment and link release services. The point-to-point data link connection endpoint states are: - link connection released state; - awaiting establish state; - awaiting release state; - link connection established state. 4.5.2.4 Sequences of primitives at one point-to-point data link connection endpoint The primitives provide the procedural means to specify concep- tually how a data link service user can invoke a service. This section defines the constraints on the sequence in which the primitives may occur. The sequences are related to the states at one point-to-point data link connection endpoint. The possible overall sequences of primitives at a point-to-point data link connection endpoint are defined in the state transition diagram, Figure 9/Q.920. The link connection released and link connection established states are stable states whilst the awaiting establish and awaiting release are transition states. 4.6 Services required from the physical layer The services provided by the physical layer are described in detail in Recommendation I.430 [8] or I.431 [9]. They are summar- ized in the following: a) physical layer connection for the transparent transmission of bits in the same order in which they are submitted to the physical layer; b) indication of the physical status of the D-channel; and c) transmission of data link layer message units according to their respective data link layer priority. Some of the above services may be implemented in the manage- ment entity on the user side or network side. The method of describing these services is by means of service primitives. The primitives between the data link layer and the physical layer are: i) PH-DATA-REQUEST/INDICATION These primitives are used to request that a message unit be sent and to indicate the arrival of a message unit. ii) Activation PH-ACTIVATE-REQUEST/INDICATION These primitives are used to request activation of the phy- sical layer connection, and to indicate that the physical layer connection has been activated. iii) Deactivation PH-DEACTIVATE-REQUEST/INDICATION This primitive is used to indicate that the physical layer connection has been deactivated. 5 Data link layer - Management structure The data link layer - management structure is shown in Figure 10/Q.920. This figure is a model shown for illustrative pur- poses only, and does not constrain implementations. The layer management entity (LME) provides for the management of resources that have a layer-wide impact. Access to the LME is provided by means of a specific SAPI. Functions provided by the LME are: - TEI assignment - TEI check - TEI removal The connection management entity (CME) provides for the management of resources that have an impact on individual connec- tions. Selection of the CME is based on a specific data link layer frame type not used in the acknowledged or unacknowledged informa- tion transfer services. Functions provided by the CME are: - parameter initialization (optional); - error processing; - connection flow control invocation. Figure 9/Q.920, p. Figure 10/Q.920, p. 5.1 Data link procedure This procedure analyzes the control field of the received frame [see Recommendation Q.921(I.441)] and provides appropriate peer-to-peer responses and layer-to-layer indications. In addition, it analyzes the data link layer service primitives and transmits the appropriate peer-to-peer commands and responses. 5.2 Multiplex procedure This procedure analyzes the flag, Frame Check Sequence (FCS), and address octets of a received frame. If the frame is correct, it distributes the frame to the appropriate data link procedures block based on the DLCI [see Recommendation Q.921(I.441)]. On frame transmission, this procedure may provide data link layer contention resolution between the various data link procedure blocks. The contention resolution is based on the SAPI value, giv- ing priority to SAPI = 0 information. 5.3 Structure of the data link procedure The functional model of the data link procedure in shown in Figure 11/Q.920. The model consists of several functional blocks for point-to-point and broadcast connections. Figure 11/Q.920, p. References [1] CCITT Recommendation Q.921(I.441) ISDN user-network interface data link layer specification . [2] CCITT Recommendation X.200 Reference model of open sys- tems interconnection for CCITT applications . [3] CCITT Recommendation X.210 OSI layer service conven- tions . [4] CCITT Recommendation X.25 Interface between data ter- minal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit . [5] ISO 3309 Data communication - High-level data link control procedures - Frame structure . [6] ISO 4335 Data communication - High-level data link control procedures - Consolidation of elements of procedures . [7] CCITT Recommendation I.320 ISDN protocol reference model . [8] CCITT Recommendation I.430 Basic user-network interface layer 1 specification . [9] CCITT Recommendation I.431 Primary rate user-network interface layer 1 specification . [10] CCITT Recommendation Q.930(I.450) ISDN user-network interface layer 3 - general aspects . [11] CCITT Recommendation Q.931(I.451) ISDN user-network interface layer 3 specification . [12] CCITT Recommendation I.412 ISDN user-network inter- faces interface structure and access capabilities . Recommendation Q.921 ISDN USER-NETWORK INTERFACE - DATA LINK LAYER SPECIFICATION 1 General This Recommendation specifies the frame structure, elements of pro cedure, format of fields and procedures for the proper opera- tion of the Link Access Procedure on the D-channel, LAPD. The concepts, terminology, overview description of LAPD func- tions and procedures, and the relationship with other Recommenda- tions are described in general terms in Recommendation Q.920(I.440) [1]. Note 1 - As stated in Recommendation Q.920(I.440), the term "data link layer" is used in the main text of this Recommendation. However, mainly in figures and tables, the terms "layer 2" and "L2" are used as abbreviations. Furthermore, in accordance with Recommendations Q.930(I.450) [2] and Q.931(I.451) [3], the term "layer 3" is used to indicate the layer above the data link layer. Note 2 - All references within this document to "layer management entity" and/or "connection management entity" refer to those entities at the data link layer. 2 Frame structure for peer-to-peer communication 2.1 General All data link layer peer-to-peer exchanges are in frames con- forming to one of the formats shown in Figure 1/Q.921. Two format types are shown in the figure: format A for frames where there is no information field and format B for frames containing an informa- tion field. 2.2 Flag sequence All frames shall start and end with the flag sequence consist- ing of one 0 bit followed by six contiguous 1 bits and one 0 bit. The flag preceding the address field is defined as the opening flag. The flag following the Frame Check Sequence (FCS) field is defined as the closing flag. The closing flag may also serve as the opening flag of the next frame, in some applications. However, all receivers must be able to accommodate receipt of one or more con- secutive flags. See ISDN User-Network Interfaces: Layer 1 Recommen- dations I.430 [4] and I.431 [5] for applicability. 2.3 Address field The address field shall consist of two octets as illustrated in Figure 1/Q.921. The address field identifies the intended receiver of a command frame and the transmitter of a response frame. The format of the address field is defined in S 3.2. A single octet address field is reserved for LAPB operation in order to allow a single LAPB [6] data link connection to be multi- plexed along with LAPD data link connections. Note - The support of a LAPB data link connection within the D-channel is optional at both the network and user side. 2.4 Control field The control field shall consist of one or two octets. Figure 1/Q.921 illustrates the two frame formats (A and B), each with a control field of one or two octets, depending upon the type of frame. The format of the control field is defined in S 3.4. Figure 1/Q.921 [T1.921], p. (A traiter comme tableau MEP) 2.5 Information field The information field of a frame, when present, follows the control field (see S 2.4 above) and precedes the frame check sequence (see S 2.7 below). The contents of the information field shall consist of an integer number of octets. The maximum number of octets in the information field is defined in S 5.9.3. 2.6 Transparency A transmitting data link layer entity shall examine the frame content between the opening and closing flag sequences, (address, control, information and FCS fields) and shall insert a 0 bit after all sequences of five contiguous 1 bits (including the last five bits of the FCS) to ensure that a flag or an abort sequence is not simulated within the frame. A receiving data link layer entity shall examine the frame contents between the opening and closing flag sequences and shall discard any 0 bit which directly follows five contiguous 1 bits. 2.7 Frame check sequence (FCS) field The FCS field shall be a 16-bit sequence. It shall be the ones complement of the sum (modulo 2) of: a) the remainder of x k(x 15 + x 14 + x 13 + x 12 + x 11 + x 10 + x 9 + x 8 + x 7 + x 6 + x 5 + x 4 + x 3 + x 2 + x + 1) divided (modulo 2) by the generator polynomial x 16 + x 12 + x 5 + 1, where k is the number of bits in the frame existing between, but not including, the final bit of the opening flag and the first bit of the FCS, excluding bits inserted for transparency, and b) the remainder of the division (modulo 2) by the generator polynomial x 16 + x 12 + x 5 + 1, of the product of x 16 by the content of the frame existing between, but not including, the final bit of the opening flag and the first bit of the FCS, excluding bits inserted for transparency. As a typical implementation at the transmitter, the initial content of the register of the device computing the remainder of the division is preset to all 1s and is then modified by division by the generator polynomial (as described above) on the address, control and information fields; the ones complement of the result- ing remainder is transmitted as the 16-bit FCS. As a typical implementation at the receiver, the initial con- tent of the register of the device computing the remainder is preset to all 1s. The final remainder, after multiplication by x 16 and then division (modulo 2) by the generator polynomial x 16 + x 12 + x 5 + 1 of the serial incoming protected bits and the FCS, will be 0001110100001111 (x 15 through x 0, respectively) in the absence of transmission errors. 2.8 Format convention 2.8.1 Numbering convention The basic convention used in this Recommendation is illus- trated in Figure 2/Q.921. The bits are grouped into octets. The bits of an octet are shown horizontally and are numbered from 1 to 8. Multiple octets are shown vertically and are numbered from 1 to n . Figure 2/Q.921 [T2.921], p. (A traiter comme tableau MEP) 2.8.2 Order of bit transmission The octets are transmitted in ascending numerical order; inside an octet bit 1 is the first bit to be transmitted. 2.8.3 Field mapping convention When a field is contained within a single octet, the lowest bit number of the field represents the lowest order value. When a field spans more than one octet, the order of bit values within each octet progressively decreases as the octet number increases. The lowest bit number associated with the field represents the lowest order value. For example, a bit number can be identified as a couple (o , b ) where o is the octet number and b is the relative bit number within the octet. Figure 3/Q.921 illustrates a field that spans from bit (1, 3) to bit (2, 7). The high order bit of the field is mapped on bit (1, 3) and the low order bit is mapped on bit (2, 7). Figure 3/Q.921 [T3.921], p. (A traiter comme tableau MEP) An exception to the preceding field mapping convention is the data link layer FCS field, which spans two octets. In this case, bit 1 of the first octet is the high order bit and bit 8 of the second octet is the low order bit (Figure 4/Q.921). Figure 4/Q.921 [T4.921], p. (A traiter comme tableau MEP) 2.9 Invalid frames An invalid frame is a frame which: a) is not properly bounded by two flags, or b) has fewer than six octets between flags of frames that contain sequence numbers and fewer than five octets between flags of frames that do not contain sequence numbers, or c) does not consist of an integral number of octets prior to zero bit insertion or following zero bit extraction, or d) contains a frame check sequence error, or e) contains a single octet address field, or f ) contains a service access point identifier (see S 3.3.3) which is not supported by the receiver. Invalid frames shall be discarded without notification to the sender. No action is taken as the result of that frame. 2.10 Frame abort Receipt of seven or more contiguous 1 bits shall be inter- preted as an abort and the data link layer shall ignore the frame currently being received. 3 Elements of procedures and formats of fields for data link layer peer-to-peer communication 3.1 General The elements of procedures define the commands and responses that are used on the data link connections carried on the D-channel. Procedures are derived from these elements of procedures and are described in S 5. 3.2 Address field format The address field format shown in Figure 5/Q.921 contains the address field extension bits , a command/response indication bit, a data link layer Service Access Point Identifier (SAPI) subfield, and a Terminal Endpoint Identifier (TEI) subfield. Figure 5/Q.921 [T5.921], p. (A traiter comme tableau MEP) 3.3 Address field variables 3.3.1 Address field extension bit (EA) The address field range is extended by reserving the first transmitted bit of the address field octets to indicate the final octet of the address field. The presence of a 1 in the first bit of an address field octet signals that it is the final octet of the address field. The double octet address field for LAPD operation shall have bit 1 of the first octet set to a 0 and bit 1 of the second octet set to 1. 3.3.2 Command/response field bit (C/R) The C/R bit identifies a frame as either a command or a response. The user side shall send commands with the C/R bit set to 0, and responses with the C/R bit set to 1. The network side shall do the opposite; that is, commands are sent with C/R set to 1, and responses are sent with C/R set to 0. The combinations for the net- work side and user side are shown in Table 1/Q.921. In conformance with HDLC rules, commands use the address of the peer data link layer entity while responses use the address of their own data link layer entity. According to these rules, both peer entities on a point-to-point data link connection use the same Data Link Connection Identifier (DLCI) composed of a SAPI-TEI where SAPI and TEI conform to the definitions contained in SS 3.3.3 and 3.3.4 and define the data link connection as described in Recommendation Q.920, S 3.4.1. H.T. [T6.921] TABLE 1/Q.921 C/R field bit usage __________________________________________________________ Command/Response Direction C/R value __________________________________________________________ Network side user side 1 Command User side network side 0 __________________________________________________________ Network side user side 0 Response User side network side 1 __________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 1/Q.921 [T6.921], p. 3.3.3 Service access point identifier (SAPI) The SAPI identifies a point at which data link layer services are provided by a data link layer entity to a layer 3 or management entity. Consequently, the SAPI specifies a data link layer entity that should process a data link layer frame and also a layer 3 or management entity which is to receive information carried by the data link layer frame. The SAPI allows 64 service access points to be specified, where bit 3 of the address field octet containing the SAPI is the least significant binary digit and bit 8 is the most significant. The SAPI values are allocated as shown in Table 2/Q.921. H.T. [T7.921] TABLE 2/Q.921 _______________________________________________________________________________ SAPI Value { Related layer 3 or management entity } _______________________________________________________________________________ 0 Call control procedures 1 { Reserved for packet mode communications using Q.931 call control procedures } 16 { Packet communication conforming to X.25 Level 3 procedures } 63 Layer 2 Management procedures All Others Reserved for future standardization _______________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note - The reservation of SAPI values for experimental purposes is for further study. Table 2/Q.921 [T7.921], p. 3.3.4 Terminal endpoint identifier (TEI) The TEI for a point-to-point data link connection may be asso- ciated with a single Terminal Equipment (TE). A TE may contain one or more TEIs used for point-to-point data transfer. The TEI for a broadcast data link connection is associated with all user side data link layer entities containing the same SAPI. The TEI subfield allows 128 values where bit 2 of the address field octet contain- ing the TEI is the least significant binary digit and bit 8 is the most significant binary digit. The following conventions shall apply in the assignment of these values. 3.3.4.1 TEI for broadcast data link connection The TEI subfield bit pattern 111 1111 (= 127) is defined as the group TEI. The group TEI is assigned to the broadcast data link connection associated with the addressed Service Access Point (SAP). 3.3.4.2 TEI for point-to-point data link connection The remaining TEI values are used for the point-to-point data link connections associated with the addressed SAP. The range of TEI values shall be allocated as shown in Table 3/Q.921. H.T. [T8.921] TABLE 3/Q.921 _______________________________________________________________ TEI Value User Type _______________________________________________________________ 0-63 { Non-automatic TEI assignment user equipment } 64-126 { Automatic TEI assignment user equipement } _______________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 3/Q.921 [T8.921], p. Non-automatic TEI values are selected by the user, and their allocation is the responsibility of the user. Automatic TEI values are selected by the network, and their allocation is the responsibility of the network. For further information regarding point-to-point situations, see Annex A. 3.4 Control field formats The control field identifies the type of frame which will be either a command or response. The control field will contain sequence numbers, where applicable. Three types of control field formats are specified: numbered information transfer (I format), supervisory functions (S format), and unnumbered information transfers and control functions (U format). The control field formats are shown in Table 4/Q.921. 3.4.1 Information transfer (I) format The I format shall be used to perform an information transfer between layer 3 entities. The functions of N(S), N(R) and P (defined in S 3.5) are independent; that is, each I frame has an N(S) sequence number, an N(R) sequence number which may or may not acknowledge additional I frames received by the data link layer entity, and a P bit that may be set to 0 or 1. The use of N(S), N(R), and P is defined in S 5. H.T. [T9.921] TABLE 4/Q.921 Control field formats ___________________________________________________________________________________ { Control field bits (modulo 128) } 8 7 6 | | | 5 | | | 4 | | | 3 | | | 2 | | | 1 ___________________________________________________________________________________ ___________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 4/Q.921 [T9.921], p. 3.4.2 Supervisory (S) format The S format shall be used to perform data link supervisory control functions such as: acknowledge I frames, request retransmission of I frames, and request a temporary suspension of transmission of I frames. The functions of N(R) and P/F are independent, that is, each supervisory frame has an N(R) sequence number which may or may not acknowledge additional I frames received by the data link layer entity, and a P/F bit that may be set to 0 or 1. 3.4.3 Unnumbered (U) format The U format shall be used to provide additional data link control functions and unnumbered information transfers for unack- nowledged information transfer. This format does not contain sequence numbers. It does include a P/F bit that may be set to 0 or 1. 3.5 Control field parameters and associated state variables The various parameters associated with the control field for- mats are described in this section. The coding of the bits within these parameters is such that the lowest numbered bit within the parameter field is the least significant bit. 3.5.1 Poll/Final (P/F) bit All frames contain the Poll/Final (P/F) bit. The P/F bit serves a function in both command frames and response frames. In command frames the P/F bit is referred to as the P bit. In response frames it is referred to as the F bit. The P bit set to 1 is used by a data link layer entity to solicit (poll) a response frame from the peer data link layer entity. The F bit set to 1 is used by a data link layer entity to indicate the response frame transmitted as a result of a soliciting (poll) command. The use of the P/F bit is described in S 5. 3.5.2 Multiple frame operation - variables and sequence numbers 3.5.2.1 Modulus Each I frame is sequentially numbered and may have the value 0 through n minus 1 (where n is the modulus of the sequence numbers). The modulus equals 128 and the sequence numbers cycle through the entire range, 0 through 127. Note - All arithmetic operations on state variables and sequence numbers contained in this Recommendation are affected by the modulus operation. 3.5.2.2 Send state variable V(S) Each point-to-point data link connection endpoint shall have an associated V(S) when using I frame commands. V(S) denotes the sequence number of the next I frame to be transmitted. The V(S) can take on the value 0 through n minus 1. The value of V(S) shall be incremented by 1 with each successive I frame transmission, and shall not exceed V(A) by more than the maximum number of outstand- ing I frames k . The value of k may be in the range of 1 k 127. 3.5.2.3 Acknowledge state variable V(A) Each point-to-point data link connection endpoint shall have an associated V(A) when using I frame commands and supervisory frame commands/responses. V(A) identifies the last frame that has been acknowledged by its peer [V(A) - 1 equals the N(S) of the last acknowledged I frame]. V(A) can take on the value 0 through n minus 1. The value of V(A) shall be updated by the valid N(R) values received from its peer (see S 3.5.2.6). A valid N(R) value is one that is in the range V(A) N(R) V(S). 3.5.2.4 Send sequence number N(S) Only I frames contain N(S), the send sequence number of transmitted I frames. At the time that an in-sequence I frame is designated for transmission, the value of N(S) is set equal to V(S). 3.5.2.5 Receive state variable V(R) Each point-to-point data link connection endpoint shall have an associated V(R) when using I frame commands and supervisory frame commands/responses. V(R) denotes the sequence number of the next in-sequence I frame expected to be received. V(R) can take on the value 0 through n minus 1. The value of V(R) shall be incre- mented by one with the receipt of an error-free, in-sequence I frame whose N(S) equals V(R). 3.5.2.6 Receive sequence number N(R) All I frames and supervisory frames contain N(R), the expected send sequence number of the next received I frame. At the time that a frame of the above types is designated for transmission, the value of N(R) is set equal to V(R). N(R) indicates that the data link layer entity transmitting the N(R) has correctly received all I frames numbered up to and including N(R) - 1. 3.5.3 Unacknowledged operation - variables and parameters No variables are defined. One parameter is defined, N201 (see S 5.9.3). 3.6 Frame types 3.6.1 Commands and responses The following commands and responses are used by either the user or the network data link layer entities and are represented in Table 5/Q.921. Each data link connection shall support the full set of commands and responses for each application implemented. The frame types associated with each of the two applications are iden- tified in Table 5/Q.921. Frame types associated with an application not implemented shall be discarded and no action shall be taken as a result of that frame. For purposes of the LAPD procedures in each application, those encodings not identified in Table 5/Q.921 are identified as unde- fined command and response control fields. The actions to be taken are specified in S 5.8.5. The commands and responses in Table 5/Q.921 are defined in SS 3.6.2-3.6.12. H.T. [T10.921] TABLE 5/Q.921 Commands and responses (modulo 128) ______________________________________________________________ Unable to convert table ______________________________________________________________ | | | | | | | | | | | | | | | | | | Table 5/Q.921 [T10.921], p. 3.6.2 Information (I) command The function of the information (I) command is to transfer, across a data link connection, sequentially numbered frames con- taining information fields provided by layer 3. This command is used in the multiple frame operation on point-to-point data link connections. 3.6.3 Set asynchronous balanced mode extended (SABME) com- mand The SABME unnumbered command is used to place the addressed user side or network side into modulo 128 multiple frame ack- nowledged operation. No information field is permitted with the SABME command. A data link layer entity confirms acceptance of an SABME command by the transmission at the first opportunity of a UA response. Upon acceptance of this command, the data link layer entity's V(S), V(A), and V(R) are set to 0. The transmission of an SABME command indicates the clearance of all exception conditions. Previously transmitted I frames that are unacknowledged when this command is processed remain unacknowledged and are discarded. It is the responsibility of a higher level (for example, layer 3) or the management entity to recover from the possible loss of the contents of such I frames. 3.6.4 Disconnect (DISC) command The DISC unnumbered command is used to terminate the multiple frame operation. No information field is permitted with the DISC command. The data link layer entity receiving the DISC command confirms the acceptance of a DISC command by the transmission of a UA response. The data link layer entity sending the DISC command terminates the multiple frame operation when it receives the acknow ledging UA or DM response. Previously transmitted I frames that are unacknowledged when this command is processed remain unacknowledged and are discarded. It is the responsibility of a higher level (for example, layer 3) or the management entity to recover from the possible loss of the contents of such I frames. 3.6.5 Unnumbered information (UI) command When a layer 3 or management entity requests unacknowledged information transfer, the UI unnumbered command is used to send information to its peer without affecting data link layer vari- ables. UI command frames do not carry a sequence number and there- fore, the UI frame may be lost without notification. 3.6.6 Receive ready (RR) command/response The RR supervisory frame is used by a data link layer entity to: a) indicate it is ready to receive an I frame; b) acknowledge previously received I frames num- bered up to and including N(R) - 1 (as defined in S 5); and c) clear a busy condition that was indicated by the earlier transmission of an RNR frame by that same data link layer entity. In addition to indicating the status of a data link layer entity, the RR command with the P bit set to 1 may be used by the data link layer entity to ask for the status of its peer data link layer entity. 3.6.7 Reject (REJ) command/response The REJ supervisory frame is used by a data link layer entity to request retransmission of I frames starting with the frame num- bered N(R). The value of N(R) in the REJ frame acknowledges I frames numbered up to and including N(R) - 1. New I frames pend- ing initial transmission shall be transmitted following the retransmitted I frame(s). Only one REJ exception condition for a given direction of information transfer is established at a time. The REJ exception condition is cleared (reset) upon the receipt of an I frame with an N(S) equal to the N(R) of the REJ frame. An optional procedure for the retransmission of a REJ response frame is described in Appendix I. The transmission of a REJ frame shall also indicate the clear- ance of any busy condition within the sending data link layer entity that was reported by the earlier transmission of an RNR frame by that same data link layer entity. In addition to indicating the status of a data link layer entity, the REJ command with P bit set to 1 may be used by the data link layer entity to ask for the status of its peer data link layer entity. 3.6.8 Receive not ready (RNR) command/response The RNR supervisory frame is used by a data link layer entity to indicate a busy condition; that is, a temporary inability to accept additional incoming I frames. The value of N(R) in the RNR frame acknowledges I frames numered up to and including N(R) - 1. In addition to indicating the status of a data link layer entity, the RNR command with the P bit set to 1 may be used by the data link layer entity to ask for the status of its peer data link layer entity. 3.6.9 Unnumbered acknowledgement (UA) response The UA unnumbered response is used by a data link layer entity to acknowledge the receipt and acceptance of the mode-setting com- mands (SABME or DISC). Received mode-setting commands are not pro- cessed until the UA response is transmitted. No information field is permitted with the UA response. The transmission of the UA response indicates the clearance of any busy condition that was reported by the earlier transmission of an RNR frame by that same data link layer entity. 3.6.10 Disconnected mode (DM) response The DM unnumbered response is used by a data link layer entity to report to its peer that the data link layer is in a state such that multiple frame operation cannot be performed. No information field is permitted with the DM response. 3.6.11 Frame reject (FRMR) response The FRMR unnumbered response may be received by a data link layer entity as a report of an error condition not recoverable by retransmission of the identical frame, i.e., at least one of the following error conditions resulting from the receipt of a valid frame: a) the receipt of a command or response control field that is undefined or not implemented; b) the receipt of a supervisory or unnumbered frame with incorrect length; c) the receipt of an invalid N(R); or d) the receipt of an I frame with an information field which exceeds the maximum established length. An undefined control field is any of the control field encod- ings that are not identified in Table 5/Q.921. A valid N(R) value is one that is in the range V(A) N(R) V(S). An information field which immediately follows the control field and consists of five octets (modulo 128 operation) is returned with this response and provides the reason for the FRMR response. This information field format is given in Figure 6/Q.921. 3.6.12 Exchange identification (XID) command/response The XID frame may contain an information field in which the identification information is conveyed. The exchange of XID frames is a compelled arrangement used in connection management (i.e., when a peer entity receives an XID command, it shall respond with an XID response at the earliest time possible). No sequence numbers are contained within the control field. The information field is not mandatory. However, if a valid XID command contains an information field and the receiver can interpret its contents, the receiver should then respond with an XID response also containing an information field. If the informa- tion field cannot be interpreted by the receiving entity, or a zero length information field has been received, an XID response frame shall be issued containing a zero length information field. The maximum length of the information field must conform to the value N201. Sending or receiving an XID frame shall have no effect on the operational mode or state variables associated with the data link layer entities. Figure 6/Q.921 [T11.921], p. (A traiter comme tableau MEP) 4 Elements for layer-to-layer communication 4.1 General Communications between layers and, for this Recommendation, between the data link layer and the layer management are accom- plished by means of primitives. Primitives represent, in an abstract way, the logical exchange of information and control between the data link and adjacent layers. They do not specify or constrain implementations. Primitives consist of commands and their respective responses associated with the services requested of a lower layer. The gen- eral syntax of a primitive is: XX - Generic name - Type: Parameters where XX designates the interface across which the primitive flows. For this Recommendation, XX is: - DL for communication between layer 3 and the data link layer; - PH for communication between the data link layer and the physical layer; - MDL for communication between the layer manage- ment and the data link layer; or - MPH for communication between the management entity and the physical layer. 4.1.1 Generic names The generic name specifies the activity that should be per- formed. Table 6/Q.921 illustrates the primitives defined in this Recommendation. Note that not all primitives have associated param- eters. H.T. [T12.921] TABLE 6/Q.921 Primitives associated with Recommendation Q.921 ______________________________________________________________________________________________________________________________________________ Type Parameters Generic name Request Indication Response Confirm Priority indicator Message unit Message unit contents ______________________________________________________________________________________________________________________________________________ { L3 <- L2 } DL-ESTABLISH X X - X - - ______________________________________________________________________________________________________________________________________________ DL-RELEASE X X - X - - ______________________________________________________________________________________________________________________________________________ DL-DATA X X - - - X { Layer 3 peer-to-peer message } ______________________________________________________________________________________________________________________________________________ DL-UNIT DATA X X - - - X { Layer 3 peer-to-peer message } ______________________________________________________________________________________________________________________________________________ { M <- L2 } MDL-ASSIGN X X - - - X TEI value, CES ______________________________________________________________________________________________________________________________________________ MDL-REMOVE X - - - - X TEI value, CES ______________________________________________________________________________________________________________________________________________ MDL-ERROR - X X - - X Reason for error message ______________________________________________________________________________________________________________________________________________ MDL-UNIT DATA X X - - - X { Management function peer-to-peer message } ______________________________________________________________________________________________________________________________________________ MDL-XID X X X X - X { Connection management information } ______________________________________________________________________________________________________________________________________________ { L2 <- L1 } PH-DATA X X - - X X { Data link layer peer-to-peer message } ______________________________________________________________________________________________________________________________________________ PH-ACTIVATE X X - - - - ______________________________________________________________________________________________________________________________________________ PH-DEACTIVATE - X - - - - ______________________________________________________________________________________________________________________________________________ { M <- L1 } MPH-ACTIVATE - X - - - - ______________________________________________________________________________________________________________________________________________ MPH-DEACTIVATE X X - - - - ______________________________________________________________________________________________________________________________________________ MPH-INFORMATION - X - - - X Connected/disconnected ______________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | L3 <- L2: Layer 3/data link layer boundary L2 <- L1: Data link layer/physical layer boundary M <- L2: Management entity/data link layer boundary M <- L1: Management entity/physical layer boundary Table 6/Q.921 [T12.921], p. The primitive generic names that are defined in this Recommen- dation are: 4.1.1.1 DL-ESTABLISH The DL-ESTABLISH primitives are used to request, indicate and confirm the outcome of the procedures for establishing multiple frame operation. 4.1.1.2 DL-RELEASE The DL-RELEASE primitives are used to request, indicate and confirm the outcome of the procedures for terminating a previously established multiple frame operation, or for reporting an unsuc- cessful establishment attempt. 4.1.1.3 DL-DATA The DL-DATA primitives are used to request and indicate layer 3 messages which are to be transmitted, or have been received, by the data link layer using the acknowledged information transfer service. 4.1.1.4 DL-UNIT DATA The DL-UNIT DATA primitives are used to request and indicate layer 3 messages which are to be transmitted, or have been received, by the data link layer using the unacknowledged informa- tion transfer service. 4.1.1.5 MDL-ASSIGN The MDL-ASSIGN primitives are used by the layer management entity to request that the data link layer associate the TEI value contained within the message unit of the primitive with the speci- fied Connection Endpoint Suffix (CES), across all SAPIs. The MDL-ASSIGN primitive is used by the data link layer to indicate to the layer management entity the need for a TEI value to be associ- ated with the CES specified in the primitive message unit. 4.1.1.6 MDL-REMOVE The MDL-REMOVE primitives are used by the layer management entity to request that the data link layer remove the association of the specified TEI value with the specified CES, across all SAPIs. The TEI and CES are specified by the MDL-REMOVE primitive message unit. 4.1.1.7 MDL-ERROR The MDL-ERROR primitives are used to indicate to the connec- tion management entity that an error has occurred, associated with a previous management function request or detected as a result of communication with the data link layer peer entity. The layer management entity may respond with an MDL-ERROR primitive if the layer management entity cannot obtain a TEI value. 4.1.1.8 MDL-UNIT DATA The MDL-UNIT DATA primitives are used to request and indicate layer management entity messages which are to be transmitted, or have been received, by the data link layer using the unacknowledged information transfer service. 4.1.1.9 MDL-XID The MDL-XID primitives are used by the connection management entity to request, indicate, respond and confirm the outcome of the actions for the use of the XID procedures. 4.1.1.10 PH-DATA The PH-DATA primitives are used to request and indicate mes- sage units containing frames used for data link layer peer-to-peer communications passed to and from the physical layer. 4.1.1.11 PH-ACTIVATE The PH-ACTIVATE primitives are used to request activation of the physical layer connection or to indicate that the physical layer connection has been activated. 4.1.1.12 PH-DEACTIVATE The PH-DEACTIVATE primitive is used to indicate that the phy- sical layer connection has been deactivated. 4.1.1.13 MPH-ACTIVATE (see Appendix III) The MPH-ACTIVATE primitive is used to indicate that the physi- cal layer connection has been activated. 4.1.1.14 MPH-DEACTIVATE (see Appendix III) The MPH-DEACTIVATE primitives are used to request deactivation of the physical layer connection or to indicate that the physical layer connection has been deactivated. The -REQUEST primitive is for use by the network side system management entity. 4.1.1.15 MPH-INFORMATION The MPH-INFORMATION primitive is for use by the user side management entity, and provides an indication as to whether the terminal is: - connected; or - disconnected or unable to provide sufficient power to support the TEI management procedures. 4.1.2 Primitive types The primitive types defined in this Recommendation are: 4.1.2.1 REQUEST The REQUEST primitive type is used when a higher layer or layer management is requesting a service from the lower layer. 4.1.2.2 INDICATION The INDICATION primitive type is used by a layer providing a service to inform the higher layer or layer management. 4.1.2.3 RESPONSE The RESPONSE primitive type is used by layer management as a consequence of the INDICATION primitive type. 4.1.2.4 CONFIRM The CONFIRM primitive type is used by the layer providing the requested service to confirm that the activity has been completed. Figure 7/Q.921 illustrates the relationship of the primitive types to layer 3 and the data link layer. 4.1.3 Parameter definition 4.1.3.1 Priority indicator Since several SAPs may exist on the network side or user side, protocol messages units sent by one SAP may contend with those of other service access points for the physical resources available for message transfer. The priority indicator is used to determine which message unit will have greater priority when contention exists. The priority indicator is only needed at the user side for distinguishing message units sent by the SAP with a SAPI value of 0 from all other message units. Figure 7/Q.921, p. 4.1.3.2 Message unit The message unit contains additional layer-to-layer informa- tion concerning actions and results associated with requests. In the case of the DATA primitives, the message unit contains the requesting layer peer-to-peer messages. For example, the DL-DATA message unit contains layer 3 information. The PH-DATA message unit contains the data link layer frame. Note - The operations across the data link layer/layer 3 boundary shall be such that the layer sending the DL-DATA or DL-UNIT DATA primitive can assume a temporal order of the bits within the message unit and that the layer receiving the primitive can reconstruct the message with its assumed temporal order. Blanc