The OSI addressing scheme is intended to support global communications. In
principle, every process in the world can be identified by an address that
is guaranteed unique. Unfortunately, possessing the address of the process
you want to contact is not much use unless it is possible to discover a
route to it and here OSI is somewhat less helpful.
Consider a print spooler and a client resident on two systems. These
are both 'Application Processes' and contain within themselves the
'Application Entities' (AE) which are the parts which are involved in OSI
communication. As far as OSI is concerned, the objective is to put AEs in
touch with each other. AEs have names, the OSI word for these is 'titles',
hence Application Entity Titles or AETs. Usually AETs are chosen to be
meaningful to people so we will call ours 'printspooler' and 'printclient'.
Note that there could be several instances of the print spooler active
simultaneously, all of these would have the same AET. Thus an AET
identifies a process type rather than a process instance.
#figure1456#
Figure: Application Layer Names - 1
#figure1461#
Figure: Application Layer Names - 2
#figure1466#
Figure: Application Layer Names - 3
The first step for the client is to map the AET to an 'address' which will
identify where the AE can be found. In the OSI model, addresses are
attached to Service Access Points (SAPs). One way of thinking about the
distinction between SAPs and addresses is to think of the difference between a
telephone socket, and the phone number associated with that socket.
A (N)-SAP is the place where an
(N+1)-Entity accesses an (N)-Service. The <#1471#> N<#1471#> refers to the layer we are
considering, so that a P-SAP refers to the presentation layer service access
point. This is analogous to the addressing
scheme used in the telephone system where the address (telephone number) is
associated with the point at which one accesses the service (the plug on
the wall) rather than with the entity doing the accessing (the telephone
hand-set). This means that an AE will be identified by the
address of the P-SAP to which it is attached. So the mapping we require is:
verbatim43
As far as OSI is concerned this mapping implies a look-up operation in some
table known as a 'directory'. No particular way of implementing a directory
is implied, in particular, the use of the ISO/CCITT standard Directory
service is not assumed. In the case of RPC type systems, servers may move
between systems fairly frequently and the provision of some form of readily
available service to locate application services is of paramount
importance. This is one of the functions of an RPC binder.
Starting from the P-SAP address, we need two pieces of information:
-
Something that will identify the host on which the print spooler can
be found.
-
Something that will identify the print spooler process on that system.
The first of these is an Network Service Access Point (N-SAP) address which
identifies the point at which the host accesses the network. Fortunately,
it is easy to extract the N-SAP address from the P-SAP address since the
latter is defined as (see #fnnsap#1474>:
verbatim44
Here, the 'selectors' (SEL) are locally meaningful values which identify
entities (and ultimately the application process) on the remote host.
Let us suppose we are using the OSI CO stack. The first step then is to try
to establish a Presentation connection so we issue a P-Connect-Request with
the P-SAP Address as a parameter. The Presentation Entity needs first to
establish a Session Connection, so it strips the P-SEL (thus generating an
S-SAP address) and issues a S-Connect-Request to the Session Layer This
process continues down through the layers. Now, let us return to the
example. Suppose the P-SAP Address is:
#table1475#
Table: Presentation Service Access Point
The fact that two of the selectors are NULL reflects the fact that only one
level of demultiplexing is required. Here is what happens:
-
A N-Connection is established between the client and server Transport
Entities. How this is done may be very complex involving finding
routes across several interconnected sub-networks. We will ignore the
details for now.
-
The client Transport Entity uses the Network connection to carry a
T-Connect PDU which includes the T-SEL ;SPM_quot;prspl;SPM_quot;.
-
At this point, we must consider the process structure of the server
system. Let us assume that the Network Entity is in the operating
system Kernel and that the Transport Entity is represented by a user
process which fields all incoming T-Connect PDUs. this is the process
T-ent-proc in figure #fn68#1482> to #fn610#1483>. T-ent-proc examines the T-SEL and maps this
(probably via a local table) to a file containing the executable
binary for the print spooler. The print spooler is now invoked and
handles all subsequent packets.
We can now see why only a T-SEL was needed. This is a result of the
particular process structure on the service system. Other structures would
use different selectors, possible all three.
T-ent-proc is an example of a 'generic server'. This sits on a system and
fields all incoming calls and then invokes the specific server required. An
alternative model - and one probably more appropriate in our case - would
have the print spooler invoked at boot time 'listening' for incoming
requests directed at its T-SAP. To an extent, the generic server model the
one favoured by OSI since there are no explicit 'listen' primitives.
However, it is quite possible to employ either model in an OSI system.