|
|
United States-English | |
|
|
 |
|
HP DLPI Programmer's Guide: HP-UX 11i v2 > Chapter 1 Introduction
to DLPI
The Data Link Layer |
|
|
The data link layer (layer 2 in the OSI Reference Model) is responsible for the transmission and error-free delivery of bits of information over a physical communications medium. The model defines networking functionality at several layers and service providers between the layers. A model of the data link layer is presented here to describe concepts that are used throughout this guide. The model is described in terms of an interface architecture, as well as addressing concepts needed to identify different components of that architecture. The description of the model assumes familiarity with the OSI Reference Model. Each layer of the OSI Reference Model has the following two standards:
DLPI is an implementation of the first type of standard. It specifies an interface to the services of the data link layer. Figure 1-1 “Abstract View of DLPI” illustrates how DLPI performs this function. The data link interface is the boundary between the network and the data link layers of the OSI Reference Model. The network layer entity is the user of the services of the data link interface (DLS user), and the data link layer entity is the provider of those services (DLS provider). This interface consists of a set of primitives that provide access to the data link layer services. In addition, it provides the rules for using those primitives (state transition rules). A data link interface service primitive might request a particular service or indicate a pending event. To provide uniformity among the various UNIX system networking products, service interfaces that map to the OSI Reference Model are developed. A set of kernel-level interfaces, based on the STREAMS development environment, constitute a major portion of this development. The service primitives that make up these interfaces are defined as STREAMS messages. These messages are transferred between the user and provider of the service. DLPI is one such kernel-level interface, and is targeted for STREAMS protocol modules that either use or provide data link services. In addition, user programs that need to access a STREAMS-based data link provider directly may do so using the putmsg(2) and getmsg(2) system calls. Referring to Figure 1-1 “Abstract View of DLPI”, the DLS provider is configured as a STREAMS driver, and the DLS user accesses the provider using open(2) to establish a stream to the DLS provider. The stream acts as a communication medium between a DLS user and the DLS provider. After the stream is created, the DLS user and DLS provider communicate via messages discussed later. DLPI is intended to free data link users from specific knowledge of the characteristics of the data link provider. Specifically, the definition of DLPI hopes to achieve the goal of allowing a DLS user to be implemented independent of a specific communication medium. Any data link provider (supporting communications medium) that conforms to the DLPI specification may be substituted beneath the DLS user to provide the data link services. Support of a new DLS provider should not require changes to the implementation of the DLS user. Although DLPI supports three modes of communication, DLPI supports connection and connectionless modes. The connection mode is circuit-oriented and enables data to be transferred over a pre-established connection in a sequenced manner. Data may be lost or corrupted in this service mode due to provider-initiated resynchronization or connection failures. The connectionless mode is message-oriented and supports data transfer in self-contained units with no logical relationship required between units. In the most general case, this service mode can be unreliable, because there is no acknowledgment of each data unit transmission. However, a specific DLS provider can provide assurance that messages will not be lost, duplicated, or reordered. HP-specific extension supports Raw mode interface. Raw mode allows the DLS user to send and receive packets with complete LLC and MAC header information. The connection-mode service is characterized by the following four phases of communication:
This phase enables a DLS user to initialize a stream for use in communication and establish an identity with the DLS provider. This phase enables two DLS users to establish a data link connection between them to exchange data. One user (caller) initiates the connection establishment procedures, while another user (callee) waits for incoming connect requests. The callee is identified by an address associated with its stream. A callee may either accept or deny a request for a data link connection. If the request is accepted, a connection is established between the DLS users, and they enter the data transfer phase. For both the caller and callee, only one connection may be established per stream. Thus, the stream is the communication endpoint for a data link connection. The callee may choose to accept a connection on the stream where it received the connect request, or it may open a new stream to the DLS provider and accept the connection on this new, responding stream. By accepting the connection on a separate stream, the initial stream can be designated as a listening stream through which all connect requests will be processed. As each request arrives, a new stream (communication endpoint) can be opened to handle the connection, enabling subsequent requests to be queued on a single stream until they can be processed. In this phase, the DLS users are considered peers and may exchange data simultaneously in both directions over an established data link connection. Either DLS user may send data to its peer DLS user at any time. Data sent by a DLS user is guaranteed to be delivered to the remote user in the order in which it was sent. The connectionless mode service does not use the connection establishment and release phases of the connection mode service. The local management phase is still required to initialize a stream. Once initialized, the connectionless data transfer phase is immediately entered. Since there is no established connection, the connectionless data transfer phase expects the DLS user to identify the destination of each data unit to be transferred. The destination DLS user is identified by the address associated with that user. Each user of DLPI must establish an identity to communicate with other data link users. This identity consists of two pieces. First, the DLS user must somehow identify the physical medium over which it will communicate. This is particularly evident on systems that are attached to multiple physical media. Second, the DLS user must register itself with the DLS provider, so that the provider can deliver protocol data units destined for that user. Figure 1-2 “Data Link Addressing Components” illustrates the components of this identification approach, which are explained in the sections that follow. The physical point of attachment (PPA in Figure 1-2 “Data Link Addressing Components”) is the point at which a system attaches itself to a physical communications medium. All communication on that physical medium funnels through the PPA. On systems where a DLS provider supports more than one physical medium, the DLS user must identify which medium it will communicate through. A PPA is identified by a unique PPA identifier. For media that supports physical layer multiplexing of multiple channels over a single physical medium (such as the B and D channels of ISDN), the PPA identifier must identify the specific channel over which communication will occur. Two styles of DLS provider are defined by DLPI, distinguished by the way they enable a DLS user to choose a particular PPA. The style 1 provider assigns a PPA based on the major/minor device the DLS user opened. This style of provider is appropriate when few PPAs will be supported. If the number of PPAs a DLS provider will support is large, a style 2 provider implementation is more suitable. The style 2 provider requires a DLS user to explicitly identify the desired PPA using a special attach service primitive. For a style 2 driver, open(2) creates a stream between the DLS user and DLS provider, and the attach primitive then associates a particular PPA with that stream. The format of the PPA identifier is specific to the DLS provider. DLPI provides a mechanism to get and/or modify the physical address. The primitives to handle these functions are described in Chapter 2. The physical address value can be modified in a postattached state. This modifies the value for all streams for that provider for a particular PPA. The DLS user uses the supported primitives, DL_ATTACH_REQ, DL_BIND_REQ, DL_ENABMULTI_REQ, and DL_PROMISCON_REQ, to define a set of enabled physical and SAP address components on a per-stream basis. The DL_ATTACH_REQ primitive addresses PPA identification (physical medium identification). It is invalid for a DLS provider to ever send upstream a data message for which the DLS user on that stream has not requested. The provider is responsible for enforcing the isolation of SAP and physical address space effects on a per-stream basis through necessary means. The PPA number passed in the DL_ATTACH_REQ primitive should correspond to one of the PPAs displayed by the lanscan(1M) command. This PPA must be supported by DLPI. Alternatively, you can obtain the PPA of the interface programmatically using the DL_HP_PPA_REQ primitive (see Chapter 2). A data link user’s identity is established by associating it with a data link service access point (DLSAP). This is the point through which the user communicates with the data link provider. A DLSAP is identified by a DLSAP address. The DLSAP address identifies a particular data link service access point that is associated with a stream (communication endpoint). The DL_BIND_REQ and DL_SUBS_BIND_REQ service primitives enable a DLS user to specify a DLSAP address. The DLSAP address can be used by other DLS users to access a specific DLS user. The format of the DLSAP address is specific to the DLS provider. However, DLPI provides a mechanism for decomposing the DLSAP address into component pieces. A DLS user can use the DL_INFO_REQ service primitive to determine the DLSAP address bound by the stream. This results in the DL_INFO_ACK service primitive, which provides length of the SAP component of the DLSAP address, along with the total length of the DLSAP address. By defining the DLSAP address, the DLS user identifies the data messages that must be passed to the DLS user. It is invalid for a DLS provider to ever send upstream a data message, which is not requested by the DLS user on that stream. Ethernet/IEEE802.3 and FDDI MAC addresses are presented in canonical format. Token Ring MAC addresses are presented in wire format. DLSAPs are what DLPI defines as an address through which the user communicates with a Data Link Service (DLS) provider. The content of the DLSAP address depends on the context in which it is used (that is, which primitive is being processed or acknowledged). The basic format of the DLSAP address is always the same. The basic DLSAP address format is as follows: | DA/SA MAC address | SAP/Ethertype | SNAP (SAP = 0xAA) | [RIF] | where, ‘[ ]’ indicates that the information is optional. The three possible variations of the DLSAP address format based on the protocol value are as follows:
where, ‘[ ]’ indicates that the information is optional.
Certain DLS providers require the capability of binding on multiple DLSAP addresses. This can be achieved through subsequent binding of DLSAP addresses. DLPI supports peer and hierarchical binding of DLSAPs. When the user requests peer addressing, the DLSAP specified in a subsequent bind may be used in lieu of the DLSAP bound in the DL_BIND_REQ. This will allow for a choice to be made between a number of DLSAPs on a stream while determining traffic based on DLSAP values. An example of this can be to specify various ether_type values as DLSAPs. The DL_BIND_REQ, for example, can be issued with an ether_type value of IP, and a subsequent bind can be issued with an ether_type value of ARP. The provider may now multiplex off the ether_type field and allow both the IP and ARP traffic to be sent up this stream. When the DLS user requests hierarchical binding, the subsequent bind specifies a DLSAP that is used in addition to the DLSAP bound using a DL_BIND_REQ. This allows additional information to be specified, which will be used in a header or for demultiplexing. An example of this can be to use hierarchical bind to specify the Organizational Unique Identifier (OUI) 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. DLPI supports the ability to associate several streams with a single DLSAP, where each stream may be a unique data link connection endpoint. However, not all DLS providers can support such configurations, because some DLS providers may have no mechanism beyond the DLSAP address for distinguishing multiple connections. In such cases, the provider restricts the DLS user to one stream per DLSAP. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
