Previous section.

Data Link Provider Interface (DLPI), Version 2
Copyright © 2000 The Open Group

Quality of Data Link Service

Characteristics

The quality of data link service is defined by the term "Quality of Service" (QOS), and describes certain characteristics of transmission between two DLS users. These characteristics are attributable solely to the DLS provider, but are observable by the DLS users. The visibility of QOS characteristics enables a DLS user to determine, and possibly negotiate, the characteristics of transmission needed to communicate with the remote DLS user.

Overview of Quality of Service

Quality of service characteristics apply to both the connection and connectionless modes of service. The semantics for each mode are discussed below.

Connection-mode Service

"Quality of Service" (QOS) refers to certain characteristics of a data link connection as observed between the connection endpoints. QOS describes the specific aspects of a data link connection that are attributable to the DLS provider.

QOS is defined in terms of QOS parameters. The parameters give DLS users a means of specifying their needs. These parameters are divided into two groups, based on how their values are determined:

The QOS parameters that can be negotiated during connection establishment are:

The QOS parameters for throughput and transit delay are negotiated end-to-end between the two DLS users and the DLS provider. The QOS parameters for priority and protection are negotiated locally by each DLS user with the DLS provider. The QOS parameters that cannot be negotiated are residual error rate and resilience. Procedures for QOS Negotiation and Selection describes the rules for QOS negotiation.

Once the connection is established, the agreed QOS values are not renegotiated at any point. There is no guarantee by any DLS provider that the original QOS values will be maintained, and the DLS users are not informed if QOS changes. The DLS provider also need only record those QOS values selected at connection establishment for return in response to the DL_INFO_REQ primitive. Quality of Data Link Service for Connectionless-mode and Acknowledged Connectionless-mode Service.

QOS for Connectionless/Acknowledged Connectionless

The QOS for connectionless-mode and acknowledged connectionless-mode service refers to characteristics of the data link layer between two DLSAPs, attributable to the DLS provider. The QOS applied to each DL_UNITDATA_REQ/DL_DATA_ACK_REQ primitive may be independent of the QOS applied to preceding and following DL_UNITDATA_REQ/DL_DATA_ACK_REQ primitives. QOS cannot be negotiated between two DLS users as in the connection-mode service.

Every DL_UNITDATA_REQ/DL_DATA_ACK_REQ primitive may have certain QOS values associated with it. The supported range of QOS parameter values is made known to the DLS user in response to the DL_INFO_REQ primitive. The DLS user may select specific QOS parameter values to be associated with subsequent data unit transmissions using the DL_UDQOS_REQ primitive. This selection is a strictly local management function. If different QOS values are to be associated with each transmission, DL_UDQOS_REQ may be issued to alter those values before each DL_UNITDATA_REQ or DL_DATA_ACK_REQ is issued.

QOS Parameter Definitions

This section describes the quality of service parameters supported by DLPI for both connection-mode and connectionless-mode services. The following table summarizes the supported parameters. It indicates to which service mode (connection, connectionless, or both) the parameter applies. For those parameters supported by the connection-mode service, the table also indicates whether the parameter value is negotiated during connection establishment. If so, the table further indicates whether the QOS values are negotiated end-to-end among both DLS users and the DLS provider, or locally for each DLS user independently with the DLS provider.

Parameter Service Mode Negotiation
throughput connection end-to-end
transit delay both end-to-end
priority both local
protection both local
residual error rate both none
resilience connection none

Table: QOS Supported Parameters

Throughput

Throughput is a connection-mode QOS parameter that has end-to-end significance. It is defined as the total number of DLSDU bits successfully transferred by a DL_DATA_REQ/DL_DATA_IND primitive sequence divided by the input/output time, in seconds, for that sequence. Successful transfer of a DLSDU is defined to occur when the DLSDU is delivered to the intended user without error, in proper sequence, and before connection termination by the receiving DLS user.

The input/output time for a DL_DATA_REQ/DL_DATA_IND primitive sequence is the greater of both:

Throughput is only meaningful for a sequence of complete DLSDUs.

Throughput is specified and negotiated for the transmit and receive directions independently at connection establishment. The throughput specification defines the target and minimum acceptable values for a connection. Each specification is an average rate.

The DLS user can delay the receipt or sending of DLSDUs. The delay caused by a DLS user is not included in calculating the average throughput values.

Parameter Format


typedef struct {
    t_scalar_t   dl_target_value;
    t_scalar_t   dl_accept_value;
} dl_through_t;


This typedef is used to negotiate the transmit and receive throughput values.

Parameter Definitions

dl_target_value

specifies the desired throughput value for the connection in bits/second.

dl_accept_value

specifies the minimum acceptable throughput value for the connection in bits/second.

Transit Delay

Connection and connectionless modes can specify a transit delay, which indicates the elapsed time between a DL_DATA_REQ or DL_UNITDATA_REQ primitive and the corresponding DL_DATA_IND or DL_UNITDATA_IND primitive. The elapsed time is only computed for DLSDUs successfully transferred, as described previously for throughput.

In connection mode, transit delay is negotiated on an end-to-end basis during connection establishment. For each connection, transit delay is negotiated for the transmit and receive directions separately by specifying the target value and maximum acceptable value. For connectionless-mode service, a DLS user selects a particular value within the supported range using the DL_UDQOS_REQ primitive, and the value may be changed for each DLSDU submitted for connectionless transmission.

The transit delay for an individual DLSDU may be increased if the receiving DLS user flow controls the interface. The average and maximum transit delay values exclude any DLS user flow control of the interface. The values are specified in milliseconds, and assume a DLSDU size of 128 octets.

Parameter Format


typedef struct {
    t_scalar_t   dl_target_value;
    t_scalar_t   dl_accept_value;
} dl_transdelay_t;


This typedef is used to negotiate the transmit and receive transit delay values.

Parameter Definitions

dl_target_value

specifies the desired transit delay value.

dl_accept_value

specifies the maximum acceptable transit delay value.

Priority

Priority is negotiated locally between each DLS user and the DLS provider in connection-mode service, and can also be specified for connectionless-mode service. The specification of priority is concerned with the relationship between connections or the relationship between connectionless data transfer requests.

The parameter specifies the relative importance of a connection with respect to:

For connectionless-mode service, the parameter specifies the relative importance of unit data objects with respect to gaining use of shared resources.

For connection-mode service, each DLS user negotiates a particular priority value with the DLS provider during connection establishment. The value is specified by a minimum and a maximum within a given range. For connectionless-mode service, a DLS user selects a particular priority value within the supported range using the DL_UDQOS_REQ primitive, and the value may be changed for each DLSDU submitted for connectionless transmission.

This parameter only has meaning in the context of some management entity or structure able to judge relative importance. The priority has local significance only, with a value of zero being the highest priority and 100 being the lowest priority.

Parameter Format


typedef struct {
    t_scalar_t   dl_min;
    t_scalar_t   dl_max;
} dl_priority_t;


Parameter Definitions

dl_min

specifies the minimum acceptable priority.

dl_max

specifies the maximum desired priority.

Protection

Protection is negotiated locally between each DLS user and the DLS provider in connection-mode service, and can also be specified for connectionless-mode service. Protection is the extent to which a DLS provider attempts to prevent unauthorized monitoring or manipulation of DLS user-originated information.

Protection is specified by a minimum and maximum protection option within the following range of possible protection options:

DL_NONE

DLS provider will not protect any DLS user data

DL_MONITOR

DLS provider will protect against passive monitoring

DL_MAXIMUM

DLS provider will protect against modification, replay, addition, or deletion of DLS user data.

For connection-mode service, each DLS user negotiates a particular value with the DLS provider during connection establishment. The value is specified by a minimum and a maximum within a given range. For connectionless-mode service, a DLS user selects a particular value within the supported range using the DL_UDQOS_REQ primitive, and the value may be changed for each DLSDU submitted for connectionless transmission. Protection has local significance only.

Parameter Format

typedef struct {
    t_scalar_t   dl_min;
    t_scalar_t   dl_max;
} dl_protect_t;


Parameter Definitions

dl_min

specifies the minimum acceptable protection.

dl_max

specifies the maximum desired protection.

Residual Error Rate

Residual error rate (RER) is the ratio of total incorrect, lost and duplicated DLSDUs to the total DLSDUs transferred between DLS users during a period of time. The relationship between these quantities is defined below:



An equation in the source document has not been converted to HTML.




where

DLSDUtot
= total DLSDUs transferred, which is the total of DLSDUl, DLSDUi, DLSDUe, and correctly received DLSDUs

DLSDUe
= DLSDUs received 2 or more times

DLSDUi
= incorrectly received DLSDUs

DLSDUl
= DLSDUs sent, but not received.

Parameter Format

t_scalar_t    l_residual_error;


The residual error value is scaled by a factor of 1,000,000, since the parameter is stored as a t_scalar_t integer in the QOS data structures. Residual error rate is not a negotiated QOS parameter. Its value is determined by procedures outside the definition of DLPI. It is assumed to be set by an administrative mechanism, which is informed of the value by network management.

Resilience

Resilience is meaningful in connection mode only, and represents the probability of either: DLS provider-initiated disconnects or DLS provider-initiated resets during a time interval of 10,000 seconds on a connection.

Resilience is not a negotiated QOS parameter. Its value is determined by procedures outside the definition of DLPI. It is assumed to be set by an administrative mechanism, which is informed of the value by network management.

Parameter Format

typedef struct {
    t_scalar_t   dl_disc_prob;
    t_scalar_t   dl_reset_prob;
} dl_resilience_t;


Parameter Definitions

dl_disc_prob

specifies the probability of receiving aprovider-initiated disconnect, scaled by 10000.

dl_reset_prob

specifies the probability of receiving aprovider-initiated reset, scaled by 10000.

QOS Data Structures

To simplify the definition of the primitives containing QOS parameters and the discussion of QOS negotiation, the QOS parameters are organized into four structures. This section defines the structures and indicates which structures apply to which primitives.

Each structure is tagged with a type field contained in the first four bytes of the structure, similar to the tagging of primitives. The type field has been defined because of the current volatility of QOS parameter definition within the international standards bodies. If new QOS parameter sets are defined in the future for the data link layer, the type field will enable DLPI to accommodate these sets without breaking existing DLS user or provider implementations. However, DLS user and provider software should be cognizant of the possibility that new QOS structure types may be defined in future issues of the DLPI specification. If a DLS provider receives a structure type that it does not understand in a given primitive, the error DL_BADQOSTYPE should be returned to the DLS user in a DL_ERROR_ACK primitive.

Currently the following QOS structure types are defined:

DL_QOS_CO_RANGE1

QOS range structure for connection-mode service for Issue 1 of DLPI

DL_QOS_CO_SEL1

QOS selection structure for connection-mode service for Issue 1 of DLPI

DL_QOS_CL_RANGE1

QOS range structure for connectionless-mode service for Issue 1 of DLPI

DL_QOS_CL_SEL1

QOS selection structure for connectionless-mode service for Issue 1 of DLPI.

The syntax and semantics of each structure type is presented in the remainder of this section.

Structure DL_QOS_CO_RANGE1

Structure type DL_QOS_CO_RANGE1 enables a DLS user and DLS provider to pass between them a range of QOS parameter values in the connection-mode service. The format of this structure type is:


typedef struct {
    t_uscalar_t            dl_qos_type;
    dl_through_t           dl_rcv_throughput;
    dl_transdelay_t        dl_rcv_trans_delay;
    dl_through_t           dl_xmt_throughput;
    dl_transdelay_t        dl_xmt_trans_delay;
    dl_priority_t          dl_priority;
    dl_protect_t           dl_protection;
    t_scalar_t             dl_residual_error;
    dl_resilience_t        dl_resilience;
} dl_qos_co_range1_t;


where the value of dl_qos_type is DL_QOS_CO_RANGE1. The fields of this structure correspond to the parameters defined in QOS Parameter Definitions. The throughput and transit delay parameters are specified for each direction of transmission on a data link connection.

This structure type is returned in the dl_qos_range_length and dl_qos_range_offset fields of the DL_INFO_ACK, and specifies the supported ranges of service quality supported by the DLS provider. In other words, it specifies the available range of QOS parameter values that may be specified on a DL_CONNECT_REQ.

For the DL_CONNECT_REQ and DL_CONNECT_IND primitives, this structure specifies the negotiable range of connection-mode QOS parameter values. See Procedures for QOS Negotiation and Selection for the semantics of this structure in these primitives.

Structure DL_QOS_CO_SEL1

Structure type DL_QOS_CO_SEL1 conveys selected QOS parameter values for connection-mode service between the DLS user and DLS provider. The format of this structure type is:


typedef struct {
    t_uscalar_t        dl_qos_type;
    t_scalar_t         dl_rcv_throughput;
    t_scalar_t         dl_rcv_trans_delay;
    t_scalar_t         dl_xmt_throughput;
    t_scalar_t         dl_xmt_trans_delay;
    t_scalar_t         dl_priority;
    t_scalar_t         dl_protection;
    t_scalar_t         dl_residual_error;
    dl_resilience_t    dl_resilience;
} dl_qos_co_sel1_t;


where the value of dl_qos_type is DL_QOS_CO_SEL1. The fields of this structure correspond to the parameters defined in QOS Parameter Definitions. The throughput and transit delay parameters are specified for each direction of transmission on a data link connection.

This structure type is returned in the dl_qos_length and dl_qos_offset fields of the DL_INFO_ACK, and specifies the current or default QOS parameter values associated with a stream. Default values are returned prior to connection establishment, and currently negotiated values are returned when a connection is active on the stream.

The structure type is used in the DL_CONNECT_RES to enable the responding DLS user to select particular QOS parameter values from the available range. The DL_CONNECT_CON primitive returns the selected values to the calling DLS user in this structure. See Procedures for QOS Negotiation and Selection for the semantics of this structure in these primitives.

Structure DL_QOS_CL_RANGE1

Structure type DL_QOS_CL_RANGE1 enables a DLS user and DLS provider to pass between them a range of QOS parameter values in the connectionless-mode service. The format of this structure type is:


typedef struct {
    t_uscalar_t        dl_qos_type;
    dl_transdelay_t    dl_trans_delay;
    dl_priority_t      dl_priority;
    dl_protect_t       dl_protection;
    t_scalar_t         dl_residual_error;
} dl_qos_cl_range1_t;


where the value of dl_qos_type is DL_QOS_CL_RANGE1. The fields of this structure correspond to the parameters defined in .

This structure type is returned in the dl_qos_range_length and dl_qos_range_offset fields of the DL_INFO_ACK, and specifies the range of connectionless-mode QOS parameter values supported by the DLS provider on the stream. The DLS user may select specific values from this range using the DL_UDQOS_REQ primitive, as described in Procedures for QOS Negotiation and Selection.

Structure DL_QOS_CL_SEL1

Structure type DL_QOS_CL_SEL1 conveys selected QOS parameter values for connectionless-mode service between the DLS user and DLS provider. The format of this structure type is:


typedef struct {
    t_uscalar_t  dl_qos_type;
    t_scalar_t   dl_trans_delay;
    t_scalar_t   dl_priority;
    t_scalar_t   dl_protection;
    t_scalar_t   dl_residual_error;
} dl_qos_cl_sel1_t;


where the value of dl_qos_type is DL_QOS_CL_SEL1. The fields of this structure correspond to the parameters defined in QOS Parameter Definitions. This structure type is returned in the dl_qos_length and dl_qos__offset fields of the DL_INFO_ACK, and specifies the current or default QOS parameter values associated with a stream. Default values are returned until the DLS user issues a DL_UDQOS_REQ to change the values, after which the currently selected values will be returned. The structure type is also used in the DL_UDQOS_REQ primitive to enable a DLS user to select particular QOS parameter values from the supported range, as described in Procedures for QOS Negotiation and Selection.

Procedures for QOS Negotiation and Selection

This section describes the methods used for negotiating and/or selecting QOS parameter values. In the connection-mode service, some QOS parameter values may be negotiated during connection establishment. For connectionless-mode service, parameter values may be selected for subsequent data transmission.

Throughout this section, two special QOS values are referenced. These are defined for all the parameters used in QOS negotiation and selection. The values are:

DL_UNKNOWN

This value indicates that the DLS provider does not know the value for the field or does not support that parameter.

DL_QOS_DONT_CARE

This value indicates that the DLS user does not care to what value the QOS parameter is set.

These values are used to distinguish between DLS providers that support and negotiate QOS parameters and those that cannot. The following sections include the interpretation of these values during QOS negotiation and selection.

Connection-mode QOS Negotiation

The current connection-mode QOS parameters can be divided into three types as follows:

The rules for processing these three types of parameters during connection establishment are described in this section.

The current definition of most existing data link protocols does not describe a mechanism for negotiating QOS parameters during connection establishment. As such, DLPI does not require every DLS provider implementation to support QOS negotiation. If a given DLS provider implementation cannot support QOS negotiation, two alternatives are available:

A DLS user need not select a specific value for each QOS parameter. The special QOS parameter value, DL_QOS_DONT_CARE, is used if the DLS user does not care what quality of service is provided for a particular parameter. The negotiation procedures presented below explain the exact semantics of this value during connection establishment.

If QOS parameters are supported by the DLS provider, the provider will define a set of default QOS parameter values that are used whenever DL_QOS_DONT_CARE is specified for a QOS parameter value. These default values can be defined for all DLS users or can be defined on a per DLS user basis. The default parameter value set is returned in the QOS field (indicated by dl_qos_length and dl_qos_offset ) of the DL_INFO_ACK before a DLS user negotiates QOS parameter values.

DLS provider addendum documentation must describe the known ranges of support for the QOS parameters and the default values, and also specify whether they are used in a local manner only.

The following procedures are used to negotiate QOS parameter values during connection establishment:

  1. The DL_CONNECT_REQ specifies the DLS user's desired range of QOS values in the dl_qos_co_range1_t structure. The target and least-acceptable values are specified for throughput and transit delay, as described in Throughput, and Transit Delay. The target value is the value desired by the calling DLS user for the QOS parameters. The least acceptable value is the lowest value the calling user will accept. These values are specified separately for both the transmit and receive directions of the connection.

    If either value is set to DL_QOS_DONT_CARE the DLS provider will supply a default value, subject to the following consistency constraints:

    For priority and protection, the DL_CONNECT_REQ specifies a minimum and maximum desired value as defined in Priority and Protection. As with throughput and transit delay, the DLS user may specify a value of DL_QOS_DONT_CARE for either the minimum or maximum value. The DLS provider will interpret this value subject to the following consistency constraints:

    The values of the residual error rate and resilience parameters in the DL_CONNECT_REQ have no meaning and are ignored by the DLS provider.

    If the value of dl_qos_length in the DL_CONNECT_REQ is set to zero by the DLS user, the DLS provider should treat all QOS parameter values as if they were set to DL_QOS_DONT_CARE, selecting any value in its supported range.

    If the DLS provider cannot support throughput, transit delay, priority, and protection values within the ranges specified in the DL_CONNECT_REQ, a DL_DISCONNECT_IND should be sent to the calling DLS user.

  2. If the requested ranges of values for throughput and transit delay in the DL_CONNECT_REQ are acceptable to the DLS provider, the QOS parameters will be adjusted to values the DLS provider will support. Only the target value may be adjusted, and it is set to a value the DLS provider is willing to provide (which may be of lower QOS than the target value). The least-acceptable value cannot be modified. The updated QOS range is then sent to the called DLS user in the dl_qos_co_range1_t structure of the DL_CONNECT_IND, where it is interpreted as the available range of service.

    If the requested range of values for priority and protection in the DL_CONNECT_REQ is acceptable to the DLS provider, an appropriate value within the range is selected and saved for each parameter; these selected values will be returned to the DLS user in the corresponding DL_CONNECT_CON primitive. Because priority and protection are negotiated locally, the DL_CONNECT_IND will not contain values selected during negotiation with the calling DLS user. Instead, the DLS provider will offer a range of values in the DL_CONNECT_IND that will be supported locally for the called DLS user.

    The DLS provider will also include the supported values for residual error rate and resilience in the DL_CONNECT_IND that is passed to the called DLS user.

    If the DLS provider does not support negotiation of throughput, transit delay, priority, or protection, a value of DL_UNKNOWN should be set in the least-acceptable, target, minimum, and maximum value fields of the DL_CONNECT_IND. Also, if the DLS provider does not support any particular QOS parameter, DL_UNKNOWN should be specified in all value fields for that parameter. If the DLS provider does not support any QOS parameters, the value of dl_qos_length may be set to zero in the DL_CONNECT_IND.

  3. Upon receiving the DL_CONNECT_IND, the called DLS user examines the QOS parameter values and selects a specific value from the proffered range of the throughput, transit delay, priority, and protection parameters. If the called DLS user does not agree on values in the given range, the connection should be refused with a DL_DISCONNECT_REQ primitive. Otherwise, the selected values are returned to the DLS provider in the dl_qos_co_sel1_t structure of the DL_CONNECT_RES primitive.

    The values of residual error rate and resilience in the DL_CONNECT_RES are ignored by the DLS provider. These parameters may not be negotiated by the called DLS user. The selected values of throughput and transit delay are meaningful, however, and are adopted for the connection by the DLS provider. Similarly, the selected priority and protection values are adopted with local significance for the called DLS user.

    If the user specifies DL_QOS_DONT_CARE for either throughput, transit delay, priority, or protection on the DL_CONNECT_RES, the DLS provider will select a value from the range specified for that parameter in the DL_CONNECT_IND primitive. Also, a value of zero in the dl_qos_length field of the DL_CONNECT_RES is equivalent to DL_QOS_DONT_CARE for all QOS parameters.

  4. Upon completion of connection establishment, the values of throughput and transit delay as selected by the called DLS user are returned to the calling DLS user in the dl_qos_co_sel1_t structure of the DL_CONNECT_CON primitive. The values of priority and protection that were selected by the DLS provider from the range indicated in the DL_CONNECT_REQ will also be returned in the DL_CONNECT_CON. This primitive will also contain the values of residual error rate and resilience associated with the newly established connection. The DLS provider also saves the negotiated QOS parameter values for the connection, so that they may be returned in response to a DL_INFO_REQ primitive.

    As with DL_CONNECT_IND, if the DLS provider does not support negotiation of throughput, transit delay, priority, or protection, a value of DL_UNKNOWN should be returned in the selected value fields. Furthermore, if the DLS provider does not support any particular QOS parameter, DL_UNKNOWN should be specified in all value fields for that parameter, or the value of dl_qos_length may be set to zero in the DL_CONNECT_CON primitive.

Connectionless-mode QOS Selection

This section describes the procedures for selecting QOS parameter values that will be associated with the transmission of connectionless data or acknowledged connectionless data.

As with connection-mode protocols, the current definition of most existing (acknowledged) connectionless data link protocols does not define a quality of service concept. As such, DLPI does not require every DLS provider implementation to support QOS parameter selection. The DLS provider may specify that any or all QOS parameters are unsupported. This is indicated to the DLS user in the DL_INFO_ACK, where the values in the supported range field (indicated by dl_qos_range_length and dl_qos_range_offset) and the current QOS field (indicated by dl_qos_length and dl_qos_offset) of this primitive are set to DL_UNKNOWN. If the DLS provider supports no QOS parameters, the QOS length fields in the DL_INFO_ACK may be set to zero.

If the DLS provider supports QOS parameter selection, the DL_INFO_ACK primitive will specify the supported range of parameter values for transit delay, priority, protection and residual error rate. Default values are also returned in the DL_INFO_ACK.

For each DL_UNITDATA_REQ or DL_DATA_ACK_REQ, the DLS provider should apply the currently selected QOS parameter values to the transmission. If no values have been selected, the default values should be used.

At any point during data transfer, the DLS user may issue a DL_UDQOS_REQ primitive to select new values for the transit delay, priority, and protection parameters. These values are selected using the dl_qos_cl_sel1_t structure. The residual error rate parameter is ignored by this primitive and cannot be set by a DLS user.

In the DL_UDQOS_REQ, the DLS user need not require a specific value for every QOS parameter. DL_QOS_DONT_CARE may be specified if the DLS user does not care what quality of service is provided for a particular parameter. When specified, the DLS provider should retain the current (or default if no previous selection has occurred) value for that parameter.

Contents Next section Index