For each area listed, a brief description is presented for the associated provider-specific item(s), including references to the appropriate description in this specification.
The format of a DLSAP address is specific to each DLS provider, as is the management of that address space. There are no restriction on the format or style of a DLSAP address. As such, a specific implementation should document the format, size, and restrictions of a DLSAP address, as well as information on how the address space is managed. For example, DLPI enables a DLS user to choose a specific DLSAP address to be bound to a stream, but a given implementation may pre-associate addresses with streams based, for example, on the major/minor device number of the stream. In this case, the DLS user could only retrieve the address associated with a stream.
If the DLS provider enables a user to select the DLSAP address for a stream, the implementation must document the contents of the dl_sap field in the DL_BIND_REQ. This field must contain sufficient information to enable the DLS provider to determine the chosen DLSAP address. This may be the full DLSAP address (if it is not larger than sizeof ( t_uscalar_t ) ), or some distinguishable part of that address. For example, an implementation of a DLS provider conforming to the ISO 8802/2 address space might allow the DSAP or SSAP portion of the DLSAP address to be specified here, where the MAC address portion remains constant over all DLSAP addresses managed by that provider.
Another aspect of address management is whether the provider supports the ability to dynamically allocate DLSAPs other than the requested DLSAP in a DL_BIND_REQ. Restrictions on DLSAPs might cover the range of supported DLSAP values, services provided by a DLSAP, connection management, and multiplexing. An example of connection management restrictions is the number of connections allowed per DLSAP. Examples of multiplexing restrictions include the number of DLSAPs per PPA, and requirements that certain DLSAPs are attached to specific PPAs.
The IEEE 802.2 link layer standard allows two ways of specifying a DLSAP value:
Previously, subnetworks used privately defined DLSAP values. As these subnetworks move into the OSI world, they may exist in environments with other vendors machines. This presents a problem because there are only 64 privately definable DLSAPS and any other vendor may choose to use these same DLSAP values.
IEEE 802.1 has defined a third way of assigning DLSAP values that will allow for unique private protocol demultiplexing. The DL_SUBS_BIND_REQ may be used to support this method.
The subsequent binding of DLSAPs can be peer or hierarchical. When the User requests peer addressing, the DL_SUBS_BIND_REQ will specify a DLSAP that may be used in lieu of the DLSAP that was bound in the DL_BIND_REQ. This will allow for a choice to be made between a number of DLSAPs on astream when determining traffic based on DLSAP values. An example of this would be to various ether_type values as DLSAPs. The DL_BIND_REQ, for example, could be issued with ether_type value of IP, and a subsequent bind could be issued with ether_type value of ARP. The provider may now multiplex off of the ether_type field and allow for either IP or ARP traffic to be sent up this stream.
When the DLS User requests hierarchical binding, the DL_SUBS_BIND_REQ will specify a DLSAP that will be used in addition to the DLSAP bound using a DL_BIND_REQ. This will allow additional information to be specified, that will be used in a header or used for demultiplexing. An example of this would be to use hierarchical bind to specify the OUI (organizationally unique identifier) to be used by SNAP.
If a DLS Provider supports peer subsequent bind operations, the first SAP that is bound is used as the source SAP when there is ambiguity.
A physical point of attachment (PPA) is referenced in DLPI by a PPA identifier, which is of type t_uscalar_t. The format of this identifier is provider-specific. The DLS provider addendum documentation should describe the format and generation of PPA identifiers for all physical media it is expected to control. It should also describe how a PPA is controlled, the capabilities of the PPA, the number of PPAs supported, and the administrative interface.
Multiplexing capabilities of a PPA should also be described in the DLS provider addendum documentation. This conveys information on the number of DLSAPs that may be supported per PPA, and the number of PPAs supported.
Another item that should be described is the manner in which a PPA is initialized.
Support of QOS parameter negotiation and selection is a provider-specific issue that must be described for each implementation. The DLS provider addendum documentation should describe which, if any, QOS parameters are supported by the provider. For parameters that are negotiated end-to-end, the addendum should describe whether the provider supports end-to-end negotiation, or whether these parameters are negotiated in a local manner only. Finally, default QOS parameter values should be documented.
The DL_INFO_ACK primitive specifies information concerning a DLS provider's restrictions and capabilities. The DLS provider addendum documentation should describe the values for all fields in the DL_INFO_ACK, and how they are determined (static, tunable, dynamic). At a minimum, the addendum must describe the provider style and the service modes supported by the DLS provider.
The overall services that a specific DLS provider supports should be described. These include whether a provider supports connection-mode service, connectionless-mode service ( acknowledged or unacknowledged) , or both, and how a DLS user selects the appropriate mode. For example, the mode may be mapped directly to a specific major/minor device, and the user selects an appropriate mode by opening the corresponding special file. Alternatively, a DLS provider which supports both modes may enable a DLS user to select the service mode on the DL_BIND_REQ.
The file name(s) used to access a particular DLS provider and/or specific service modes of that provider must also be documented.
| Contents | Next section | Index |