• ↑↓ pour naviguer
  • pour ouvrir
  • pour sélectionner
  • ⌘ ⌥ ↵ pour ouvrir dans un panneau
  • ←→ pour naviguer
  • esc pour rejeter
⌘ '
raccourcis clavier

The Problem

Layers need a standardized way to communicate across the service interface. Without defined operations, each implementation would have ad-hoc interfaces making layers non-interchangeable.

Core Idea

The set of operations or function calls available at a Service Access Point (SAP) for requesting services, receiving indications, and confirming operations.

How It Works

  1. Request: Upper layer asks lower layer to perform an action (e.g., send data)
  2. Indication: Lower layer notifies upper layer of an event (e.g., data received)
  3. Response: Upper layer replies to an indication from lower layer
  4. Confirm: Lower layer acknowledges completion of a requested action

Visual Explanation

G Upper Upper Layer SAP Service Access Point Upper->SAP 1. Request Upper->SAP 3. Response SAP->Upper Notify SAP->Upper Complete Lower Lower Layer SAP->Lower Process SAP->Lower Reply Lower->SAP 2. Indication Lower->SAP 4. Confirm

Key Properties

  • Four basic types: Request, Indication, Response, Confirm
  • Implemented as API calls in real systems (e.g., socket API)
  • Define the contract between adjacent layers
  • Enable standardized layer interaction

Connections

  • Built from: Service Access Point — where primitives are invoked
  • Built from: Service — the operations that implement the service
  • Related: Socket API — concrete implementation of primitives
  • Related: Layered Model — primitives operate between layers

Edge Cases & Gotchas

  • Not all primitives are used for every service (connectionless may not need confirm)
  • Primitive ordering matters — must follow the request-indication-response-confirm pattern
  • Some implementations combine primitives (e.g., synchronous calls that block until confirm)