Establish and maintain synchronized communication sessions between users/applications operating at higher (presentation/application) layers

1. Session management

• Protocols to establish connection,
• Protocols to maintain connection, and re-establish if lost
• Protocols to disconnect

2. Dialog management

• e.g. Enforcing a half-duplex (sequential) communication
• transport connection may be full-duplex
• session layer forces transaction activities to be half-duplex
• such a protocol may use a token to enforce
• example: cannot issue second query until received reply to first one
• example: automated teller (ATM) operation

3. Synchronization

• State to which session can be "rolled back" if problem occurs
• Major and minor synchronization points
• Major: must be acknowledged by user before session can continue
• Minor: checkpoints that need not be explicitly acknowledged

4. Thread management

• Only if multiple activity threads occur in session

1. Data translation

• Example: ASCII vs. EBCDIC
• Example: one's complement vs. two's complement
• Example: big-endian vs. little-endian
• Where should translation occur?
  Suppose sender uses encoding A, receiver uses encoding B
• At sender: sender translates A->B, transmits B (ADV/DIS)
• At receiver: sender transmits A, receiver translates A->B (ADV/DIS)
• Indirect: sender translates A->C, transmits C, receiver translates C->B. C must be a standard machine-independent encoding (ADV/DIS)
• ISO 8824 specifies Abstract Syntax Notation 1 (ASN.1) as object-based machine-independent format.

2. Data Compression

• Run length compression
• Best when data contain long runs of repeated symbol (bit, byte, etc)
• Replace run with: marker, symbol, number of occurrences (fixed length or use end marker)
• Statistical compression
• Design encoding scheme such that:
  higher the frequency of symbol occurrence, the shorter its code
• Example: Morse code
• Example: Huffman coding. Essence of encoding strategy:
  - build binary tree of symbols, level based on frequency (highest at root)

• Relative or differential compression
• Start with full frame
• each subsequent frame contains only difference between it and previous
• (remember the 5-bit differential encoding assignment?).

3. Encryption/Decryption

• Cryptology: study of ciphers
• Cryptography: designing ciphers
• Cryptanalysis: breaking ciphers
• Method requires algorithm(s) and key(s)
• Traditional methods
• Substitutions (disguise symbols)
• Transposition (re-order symbols)
• Combination of the two
• Requirements:
• key known only to sender and receiver
• decryption algorithm exists

• public key cryptography
• developed by Hellman and Diffie at Stanford (1976)
• Essence:
• Encryption algorithm E is public and uses public key
• Decryption algorithm D is private and uses private key
• Plaintext message P.
• Characteristics of algorithms D and E:

0. D (private) is "very difficult" to deduce from E
1. E (public) cannot be broken by plaintext attack
2. D(E(P) ) = P

• Procedure:

0. Sender encrypts P using receiver's public algorithm and key E_R
1. Sender transmits E_R(P)
2. Receiver decrypts using its private key: D_R(E_R(P)) = P !

• And many more (that time does not permit), such as
• Data Encryption Standard (DES), developed by IBM in 70s
• Escrowed Encryption Standard, including Clipper chip and skipjack algorithm, that allows government a back-door key
• Rivest, Shamir, Adleman (RSA), a public-key encryption method

4. Authentication

• Assuring that message comes from who it says it does : digital signature
• extends public key encryption by adding fourth characteristic: E(D(P)) = P
• procedure:

1. sender applies its private D_S to P
2. sender encrypts the result using receiver's public E_R
3. sender transmits result: E_R(D_S(P))
4. receiver applies its private D_R to get D_R(E_R(D_S(P))), which is D_S(P)
5. receiver applies sender's public E_S to get E_S(D_S(P)), which is P !

• If the message had come from a different sender, last step would fail.

Application programs intended for end use.

These are so varied in nature as to defy standardization.

Textbook describes some common applications for which ITU-T standards exist

Last reviewed: 27 April 1998