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.
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.
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.
| 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 |
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.
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.
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.
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.
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.
typedef struct {
t_scalar_t dl_min;
t_scalar_t dl_max;
} dl_priority_t;
Protection is specified by a minimum and maximum protection option within the following range of possible protection options:
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.
typedef struct {
t_scalar_t dl_min;
t_scalar_t dl_max;
} dl_protect_t;
where
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 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.
typedef struct {
t_scalar_t dl_disc_prob;
t_scalar_t dl_reset_prob;
} dl_resilience_t;
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:
The syntax and semantics of each structure type is presented in the remainder of this section.
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
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
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
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
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
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
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:
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.
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:
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
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.
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.
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.
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.
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 |