Naming, Addressing and Routing

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.

Figure: Application Layer Names - 1

Figure: Application Layer Names - 2

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:

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:

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:

  1. 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.
  2. The client Transport Entity uses the Network connection to carry a T-Connect PDU which includes the T-SEL ;SPM_quot;prspl;SPM_quot;.
  3. 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.