OSI Model Upper Layers: Session, Presentation, and Application

Having explored the Session, Presentation, and Application layers individually, we now examine how these layers interact with each other and with the Transport layer below. Understanding these interactions is crucial for comprehending the complete flow of data through the OSI model.

The OSI model's layered architecture operates like a symphony orchestra—each section (layer) has distinct responsibilities, but the music (communication) only emerges when they work together in harmony. The Application layer provides the melody (the service), the Presentation layer ensures everyone reads the same sheet music (encoding), the Session layer keeps time (dialogue control), and the Transport layer ensures the notes reach the audience (delivery).

This page traces how a message travels from an application through the upper layers, examines the interfaces between layers, and illustrates the encapsulation process that packages data for transmission.

In the OSI model, adjacent layers communicate through well-defined Service Access Points (SAPs). Each layer provides services to the layer above it and consumes services from the layer below it.

The SAP Concept:

A Service Access Point is a logical interface where one layer accesses services from the layer below. It's identified by an address (the SAP address) that allows multiplexing—multiple higher-layer entities can use the same lower-layer provider.

                    Layer N+1
                        |
                        | (N)-SAP (Service Access Point)
                        |
                        v
             +-------------------+
             |    Layer N        |
             |  (Service Provider)|
             +-------------------+
                        |
                        | (N-1)-SAP
                        |
                        v
                    Layer N-1

SAPs in the Upper Layers:

Service Primitives:

Layers communicate through service primitives—defined interactions that request services or notify of events:

Confirmed vs. Unconfirmed Services:

• Confirmed Service: Involves all four primitives (request → indication → response → confirm). The initiator receives feedback.
• Unconfirmed Service: Only request → indication. No acknowledgment to initiator.

Confirmed Service:                 Unconfirmed Service:

  User A         User B              User A         User B
    |              |                    |              |
    | Request      |                    | Request      |
    |----->        |                    |----->        |
    |        Indication                 |        Indication
    |              |                    |              |
    |        Response                   +==============+
    |       <------|                    (No response)
    | Confirm      |
    |<-----        |
    |              |

While vertical communication is local (within one system), horizontal communication occurs between peer entities at the same layer on different systems. This peer-to-peer communication implements the actual network protocols.

The Protocol vs. Service Distinction:

   System A                                     System B
+------------+                               +------------+
| Layer N+1  |                               | Layer N+1  |
+------------+                               +------------+
      | (Service)                                   |
      v                                            v
+------------+  <--- Layer N Protocol --->   +------------+
| Layer N    |  (Horizontal Communication)   | Layer N    |
+------------+                               +------------+
      | (Service)                                   |
      v                                            v
+------------+                               +------------+
| Layer N-1  |  <--- Layer N-1 Protocol ---> | Layer N-1  |
+------------+                               +------------+

Key Insight: Layer N entities never communicate directly across the network. They use Layer N-1's service to exchange their protocol messages. This continues down the stack until Layer 1 (Physical), which actually transmits bits.

For Example (Application Layer HTTP):

1. Application Layer on System A formats an HTTP request
2. HTTP request is passed DOWN to Presentation Layer (encoding)
3. Down to Session Layer (dialogue management)
4. Down to Transport Layer (TCP segmentation)
5. Down to Network Layer (IP routing)
6. Down to Data Link Layer (framing)
7. Down to Physical Layer (bit transmission)
8. Bits travel across the network
9. Physical Layer on System B receives bits
10. UP through each layer, each processing its headers
11. Application Layer on System B receives HTTP request

From the Application Layer's perspective, it's talking directly to its peer. The intervening layers are transparent.

As data flows down through the layers, each layer adds its own header (and sometimes trailer) information—a process called encapsulation. The data unit at each layer has a specific name:

Protocol Data Unit (PDU) Names:

The Encapsulation Process:

Application Layer:
[       Application Data (APDU)        ]

Presentation Layer (adds header):
[PH][      Application Data            ]
    ^-- Presentation Header

Session Layer (adds header):
[SH][PH][    Application Data          ]
  ^-- Session Header

Transport Layer (adds header):
[TH][SH][PH][ Application Data         ]
  ^-- Transport Header (port numbers, seq#)

Network Layer (adds header):
[NH][TH][SH][PH][ Application Data     ]
  ^-- Network Header (IP addresses)

Data Link Layer (adds header AND trailer):
[DH][NH][TH][SH][PH][App Data      ][DT]
  ^-- Data Link Header     ^-- Data Link Trailer
      (MAC addresses)          (CRC checksum)

Physical Layer:
1011010101100101010111001010101001010...

Decapsulation (Receiving Side):

When data arrives at the destination, the reverse process occurs:

1. Physical Layer converts bits to frame
2. Data Link Layer validates checksum, strips DH/DT, passes packet up
3. Network Layer reads NH, verifies destination, strips NH, passes segment up
4. Transport Layer reads TH, reassembles/orders segments, strips TH, passes SPDU up
5. Session Layer processes session controls, strips SH, passes PPDU up
6. Presentation Layer decodes/decrypts data, strips PH, passes APDU up
7. Application Layer processes application data

Header Information Summary:

The interface between the Application and Presentation layers handles the translation between application-oriented data and network-transmissible representations.

Services Provided to Application Layer:

Presentation Context Negotiation:

Before data exchange, the Application and Presentation layers must agree on how data will be represented:

Application Layer                    Presentation Layer
       |                                    |
       | P-CONNECT.request                  |
       | (proposed presentation contexts)   |
       |----------------------------------->|
       |                                    |
       |                    [Negotiate with |
       |                     peer entity]   |
       |                                    |
       | P-CONNECT.confirm                  |
       | (accepted contexts)                |
       |<-----------------------------------|
       |                                    |

Example: Application Requesting Service:

1. Application creates a structured data object (e.g., a UserProfile)
2. Application calls P-DATA.request(UserProfile, context=1)
3. Presentation Layer:
   • Looks up context 1 (e.g., ASN.1 + DER encoding)
   • Serializes UserProfile into DER-encoded bytes
   • Optionally encrypts and/or compresses
   • Passes bytes to Session Layer
4. At receiver:
   • Presentation Layer reverses the process
   • Delivers reconstructed UserProfile via P-DATA.indication

In TCP/IP Networks:

In practice, these functions are often merged:

Example: HTTP Content Negotiation

Client Request:
GET /api/user/123 HTTP/1.1
Host: api.example.com
Accept: application/json, application/xml;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5

Server Response:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Content-Language: en

[gzip-compressed JSON data]

This HTTP exchange demonstrates Application/Presentation layer negotiation:

• Client proposes formats (JSON preferred, XML acceptable)
• Client indicates compression support
• Server responds with chosen format and encoding

The Presentation Layer relies on Session Layer services for dialogue management while focusing on data representation concerns.

Services Consumed from Session Layer:

How Presentation Uses Session Services:

Presentation Layer Operations:

1. Context Establishment:
   P-CONNECT.request → S-CONNECT.request
   (Presentation context list carried in session user data)

2. Data Transfer:
   P-DATA.request(encoded data) → S-DATA.request(PPDU)
   (Session ensures ordered, reliable delivery)

3. Synchronization:
   Presentation can request session sync points
   to checkpoint encoding state for recovery

4. Context Release:
   P-RELEASE.request → S-RELEASE.request
   (Presentation contexts are released with session)

Multiplexing Considerations:

A single session connection might carry multiple presentation contexts:

Session Connection
    |
    +-- Presentation Context 1: JSON data
    |
    +-- Presentation Context 2: Binary images
    |
    +-- Presentation Context 3: Encrypted control messages

The Presentation Layer labels each PPDU with its context identifier, and the Session Layer delivers them in order.

The Session Layer relies on Transport Layer services for reliable (or unreliable) data delivery between endpoints. This interface is crucial because the Transport Layer is the last layer that provides end-to-end service.

Services Consumed from Transport Layer:

Session Connection to Transport Connection Mapping:

The OSI model allows flexible relationships:

Session Recovery Over Transport:

Session A established
Transport connection active
    |
    | [Transport connection fails]
    |
Session Layer detects failure
    |
    | [Re-establish transport connection]
    |
Session Layer resynchronizes to last checkpoint
    |
Data transfer resumes (no application awareness needed)

This is a key capability of the Session Layer: providing continuity above transport interruptions.

Transport Service Primitives Used by Session:

Quality of Service Mapping:

The Session Layer maps its QoS requirements to Transport Layer capabilities:

Port Multiplexing:

The Transport Layer uses port numbers to multiplex multiple sessions over a single host:

             Host A (192.168.1.10)
                    |
    +---------------+---------------+
    |               |               |
 Port 50001    Port 50002      Port 50003
    |               |               |
Session A      Session B       Session C
    |               |               |
    +---------------+---------------+
                    |
             To Server (80/443)

Each session has a unique (src-IP, src-port, dest-IP, dest-port) tuple.

Let's trace a complete HTTPS request through all seven OSI layers to see the interactions we've discussed in action.

Scenario: User opens https://api.example.com/users/42 in their browser.

Step-by-Step Flow:

Network Transit:

The bits travel through:

• Ethernet cable to home router
• Router converts to ISP's network technology
• Multiple router hops (examined at Layer 3)
• Through internet exchange points
• To server's data center
• Finally to the server's NIC

Receiver Side (Upward):

The Response Follows the Reverse Path:

1. Application Layer generates HTTP response with JSON body
2. Presentation Layer compresses (gzip), encrypts (TLS)
3. Session Layer maintains TLS session state
4. Transport Layer segments, adds TCP headers
5. Network Layer adds IP headers, routes
6. Data Link Layer frames for local network
7. Physical Layer transmits

Complete Round-Trip Summary:

[Browser] → [TLS Encrypt] → [TCP Segment] → [IP Route] → [Ethernet] → 
    → [Internet Transit] →
[Ethernet] → [IP Deliver] → [TCP Reassemble] → [TLS Decrypt] → [Web Server]
    |
    v (Process request)
    |
[Web Server] → [TLS Encrypt] → [TCP Segment] → [IP Route] → [Ethernet] →
    → [Internet Transit] →
[Ethernet] → [IP Deliver] → [TCP Reassemble] → [TLS Decrypt] → [Browser]

In real software systems, the clean OSI layer separation manifests as design patterns and architectural decisions. Understanding these patterns helps you build better networked applications.

Pattern 1: The Protocol Stack Pattern

Implement each layer as a separate component with defined interfaces:

                 Application
                     |
              +------+------+
              | SerializerLayer | ← Presentation
              +------+------+
                     |
              +------+------+
              | SessionManager  | ← Session
              +------+------+
                     |
              +------+------+
              |  SocketLayer    | ← Transport
              +------+------+
                     |
              (OS Network Stack)

Pattern 2: Middleware Chain

Layers implemented as interceptors/middleware that wrap each other:

// Conceptual middleware chain
const requestPipeline = compose(
    applicationLayer,      // Parse/generate HTTP
    compressionLayer,      // gzip (Presentation)
    encryptionLayer,       // TLS (Presentation/Session)
    sessionLayer,          // Cookie/session management
    transportLayer         // TCP connection
);

// Each layer wraps the next
function compressionLayer(inner) {
    return {
        send: (data) => inner.send(compress(data)),
        receive: () => decompress(inner.receive())
    };
}

Pattern 3: Event-Driven Layer Communication

Layers communicate through events rather than direct calls:

Transport Layer emits: 'data-received' event
Session Layer subscribes: handles reassembly, emits 'session-data-ready'
Presentation Layer subscribes: decodes, emits 'decoded-message'
Application Layer subscribes: processes business logic

Pattern 4: Decorator Pattern for Layer Services

Each layer decorates lower-layer services with additional functionality:

class EncryptedSocket:  # Presentation Layer decorator
    def __init__(self, raw_socket, cipher):
        self.socket = raw_socket
        self.cipher = cipher
    
    def send(self, data):
        encrypted = self.cipher.encrypt(data)
        self.socket.send(encrypted)
    
    def recv(self):
        encrypted = self.socket.recv()
        return self.cipher.decrypt(encrypted)

# Usage
raw = socket.socket(socket.AF_INET, socket.SOCK_STREAM)  # L4
encrypted = EncryptedSocket(raw, cipher)                  # L5/L6

Pattern 5: Headers as Layer Metadata

Each layer's state is encoded in headers/metadata structures:

class HTTPRequest:        # L7 metadata
    method: str
    path: str
    headers: dict
    body: bytes

class TLSRecord:          # L5/L6 metadata
    content_type: int
    version: tuple
    payload: bytes

class TCPHeader:          # L4 metadata
    src_port: int
    dst_port: int
    seq_num: int
    ack_num: int
    flags: int

The OSI upper layers—Session, Presentation, and Application—work together as an integrated system to deliver useful network services. Understanding their interactions enriches your ability to design, implement, and debug networked systems.

Looking Ahead:

With a thorough understanding of the Session, Presentation, and Application layers, and how they interact, we can now appreciate the importance of these upper layers in the complete OSI model. The next page examines the overall importance of the OSI model—why this theoretical framework remains relevant decades after its creation, even as the Internet evolved with the TCP/IP model.