protocols and services - dtu

Protocols and ServicesRobin Sharprobin@imm.dtu.dk

Systems Security Group

Informatics and Mathematical Modelling

Technical University of Denmark

DK-2800 Kgs. Lyngby, Denmark.

Course 02221/02222, DTU, Spring 2008. – p. 1/2

1: SERVICES AND LAYERING

VIEWS OF A SYSTEM

Most abstract view: Participating processes interact at a commonINTERACTION POINT, for example a shared channel:�

�Process A

�Process B�

VIEWS OF A SYSTEM

Most abstract view: Participating processes interact at a commonINTERACTION POINT, for example a shared channel:�

�Process A

�Process B�

Difficult to make realistic, for example to describe errors!

More realistic view: Describe the interaction by a PROCESS.

This process describes the SERVICE offered by the infrastructure.�

�Process A

�Process B�

�Service S

�IAS

�IBS

VIEWS OF A SYSTEM (2)

In a distributed system, the SERVICE will typically be implementedby cooperation between two or more active ENTITIES, whichcommunicate using a PROTOCOL over an underlying SERVICE:�

�Process A

�Process B�

S�IAS�IBS

�PB�

�SAB

�I ′AS

�I ′BS

VIEWS OF A SYSTEM (2)

In a distributed system, the SERVICE will typically be implementedby cooperation between two or more active ENTITIES, whichcommunicate using a PROTOCOL over an underlying SERVICE:�

�Process A

�Process B�

S�IAS�IBS

�PB�

�SAB

�I ′AS

�I ′BS

The underlying service (here SAB) may itself be implemented by aset of protocol entities and a further underlying service.

And so on . . . .

SOME (OSI) NOTATION��

��User A

��

��User B�

(N)-SERVICE��

��PA

��

��PB�

��(N-1)-

SERVICE

�SAPA�SAPB

� �

OSI builds on the fundamental idea that communication systems have aLAYERED ARCHITECTURE.

Service offered by layer N builds on underlying service in layer (N − 1).

The extra “value” offered by layer N is provided by cooperation betweentwo or more (N)-ENTITIES, which obey the rules of an (N)-PROTOCOL.

Users of the (N)-SERVICE ((N)-USERS) are entities in layer (N + 1).

The interaction point between an (N)-USER and the (N)-SERVICE is knownas an (N)-SERVICE-ACCESS-POINT (or just (N)-SAP).

OSI LAYERING IN CSP��

��UserA

��

��UserB�

S′��

��PA

��

��PB�

��S

�SAPA �SAPB

�cl �cr

Model services and protocol entities by CSP PROCESSES,e.g. UserA, UserB, PA, PB, S, S′, . . .

Model SAPs by CSP CHANNELS, e.g. SAPA, SAPB, cl, cr, . . .

Model composition of the service by PIPING.Typically, for a two-party protocol: S′ = PA � S � PB.

Notice channel naming conventions: Processes traditionally described interms of channels left and right.Piping P � Q involves connecting channel right of P to channel left ofQ and RENAMING them both to the same new name.

2: PROVING PROPERTIES OF ACOMPOSED SERVICE

A SIMPLE ACK/NACK PROTOCOL

Senderdef= (SAPA?x : M →Q[x])

Q[x : M] def= (right!x → (right?y : {ACK} → Sender

[]right?y : {NACK} → Q[x]))

Receiverdef= (left?x : M → left!ACK → SAPB!x → Receiver

[]left?y : M′ → left!NACK → Receiver)

A SIMPLE ACK/NACK PROTOCOL

Senderdef= (SAPA?x : M →Q[x])

Q[x : M] def= (right!x → (right?y : {ACK} → Sender

[]right?y : {NACK} → Q[x]))

Receiverdef= (left?x : M → left!ACK → SAPB!x → Receiver

[]left?y : M′ → left!NACK → Receiver)

Sender ReceiverSAPA� SAPB�� right left

Notice that direct connection of Sender to Receiver gives perfect,loss-free transmission of data:

Systemdef= Sender � Receiver

System = (SAPA?x : M → (SAPB!x → System))

But what if the system is Sender � S � Receiver, where S is notperfect?

PROTOCOL + UNDERLYING SERVICE

Sender ReceiverMA

�SAPA �SAPB� �

MM� �

Underlying service described by:

Mediumdef= (MM ||| MA)

MMdef= (left?x : M → ( right!x → MM

�right!y → MM) )

MAdef= (right?a : K → left!a → MA )

where:M is domain of correct messagesM′ is domain of corrupt messages, y ∈ M′, (M′ ∩M) = ∅K = {ACK, NACK} is domain of acknowledgments

We assume that acknowledgments never get lost or corrupted!

PROTOCOL + UNDERLYING SERVICE

Sender ReceiverMA

�SAPA �SAPB� �

MM� �

Underlying service described by:

Mediumdef= (MM ||| MA)

MMdef= (left?x : M → ( right!x → MM

�right!y → MM) )

MAdef= (right?a : K → left!a → MA )

where:M is domain of correct messagesM′ is domain of corrupt messages, y ∈ M′, (M′ ∩M) = ∅K = {ACK, NACK} is domain of acknowledgments

We assume that acknowledgments never get lost or corrupted!

It is not true that Medium sat right � left.But is it true that S ′ sat SAPB � SAPA? Where:

S ′ def= Sender � Medium � ReceiverCourse 02221/02222, DTU, Spring 2008. – p. 9/2

FILTER FUNCTIONS

Protocol includes acknowledgments and retransmissions.

So when user sends 〈m1,m2,m3,m4, . . .〉 at SAPA, sequence ofmessages in Medium may be, say:

〈m1, ACK, m̃2, NACK,m2, ACK, m̃3, NACK, m̃3, NACK,m3, ACK,m4, ACK, . . .〉

(where m̃2, m̃3 are corrupted.) This looks completely different!

To allow for this in our proof, we introduce a FILTER FUNCTION,f(s), which can remove the “extra” messages from trace s.

In the current case, we need to cancel all occurrences of ACK, andall consecutive pairs 〈x, NACK〉.

FILTER FUNCTIONS

Protocol includes acknowledgments and retransmissions.

So when user sends 〈m1,m2,m3,m4, . . .〉 at SAPA, sequence ofmessages in Medium may be, say:

〈m1, ACK, m̃2, NACK,m2, ACK, m̃3, NACK, m̃3, NACK,m3, ACK,m4, ACK, . . .〉

(where m̃2, m̃3 are corrupted.) This looks completely different!

To allow for this in our proof, we introduce a FILTER FUNCTION,f(s), which can remove the “extra” messages from trace s.

In the current case, we need to cancel all occurrences of ACK, andall consecutive pairs 〈x, NACK〉.Suitable filter function is defined by:

f(〈〉) = 〈〉f(〈x〉) = 〈x〉f(〈x〉̂〈ACK〉̂c) = 〈x〉̂f(c)f(〈x〉̂〈NACK〉̂c) = f(c) Course 02221/02222, DTU, Spring 2008. – p. 10/2

PROOF IDEAGiven the filter function:

f(〈〉) = 〈〉f(〈x〉) = 〈x〉f(〈x〉̂〈ACK〉̂c) = 〈x〉̂f(c)f(〈x〉̂〈NACK〉̂c) = f(c)

Try to prove three subsidiary assertions:Sender sat f(right) � SAPA

Receiver sat SAPB � f(left)Medium sat left � K � right � K

where c � K for channel c means the channel history of cRESTRICTED to messages in domain K.

PROOF IDEAGiven the filter function:

f(〈〉) = 〈〉f(〈x〉) = 〈x〉f(〈x〉̂〈ACK〉̂c) = 〈x〉̂f(c)f(〈x〉̂〈NACK〉̂c) = f(c)

Try to prove three subsidiary assertions:Sender sat f(right) � SAPA

where c � K for channel c means the channel history of cRESTRICTED to messages in domain K.

These look intuitively true! For example:

Sender�〈m1,m2,m3〉SAPA

�〈m1, ACK,m2, NACK,m2, ACK,m3, ACK〉right

PROOF FOR ReceiverReceiver has recursive def., so use rules for recursive proof.Initially assume Receiver sat SAPB � f(left). Then:

1. ⇒ {Definitions of �, f }� 〈〉 � f(〈〉)

2. ⇒ {Assumption, Definition of �, f }Γ2 � Receiver sat 〈x〉̂SAPB � f(〈x〉̂〈ACK〉̂left)

3. ⇒ {Definition of �, f }� 〈〉 � f(〈x〉̂〈ACK〉̂〈〉)

4. ⇒ {2, 3, Output}Γ2 � (SAPB!x → Receiver) sat SAPB � f(〈x〉̂〈ACK〉̂left)

5. ⇒ {Definition of �}� 〈〉 � f(〈x〉)

6. ⇒ {4, 5, Output}Γ2 � (left!ACK → SAPB!x → Receiver) sat SAPB � f(〈x〉̂left)

7. ⇒ {6, ∀-introduction}Γ2 � ∀v ∈ M · (left!ACK → SAPB!v → Receiver)

sat SAPB � f(〈v〉̂left)Course 02221/02222, DTU, Spring 2008. – p. 12/2

PROOF FOR Receiver (continued)7. ⇒ {6, ∀-introduction}

Γ2 � ∀v ∈ M · (left!ACK → SAPB!v → Receiver)sat SAPB � f(〈v〉̂left)

8. ⇒ {Definition of �, f }� 〈〉 � f(〈〉)

9. ⇒ {7, 8, Input}Γ2 � (left?x : M → left!ACK → SAPB!x → Receiver)

sat SAPB � f(left)

10. ⇒ {Assumption, definition of f }Γ2 � Receiver sat SAPB � f(〈x〉̂〈NACK〉̂left)

11. ⇒ {Definitions of �, f }� 〈〉 � f(〈x〉̂〈〉)

12. ⇒ {10, 11, Output}Γ2 � (left!NACK → Receiver) sat SAPB � f(〈x〉̂left)

13. ⇒ {12, ∀-introduction}Γ2 � ∀v ∈ M′ · (left!NACK → Receiver) sat SAPB � f(〈v〉̂left)

PROOF FOR Receiver (continued)13. ⇒ {12, ∀-introduction}

Γ2 � ∀v ∈ M′ · (left!NACK → Receiver) sat SAPB � f(〈v〉̂left)

14. ⇒ {Definitions of �, f }� 〈〉 � f(〈〉)

15. ⇒ {13, 14, Input}Γ2 � (left?y : M′ → left!NACK → Receiver) sat SAPB � f(left)

16. ⇒ {9, 15, Alternative}

Γ2 � (left?x : M → left!ACK → SAPB!x → Receiver

[]left?y : M′ → left!NACK → Receiver)sat SAPB � f(left)

17. ⇒ {1, 16, Recursion}

Γ2 � Receiver sat SAPB � f(left)

This completes the proof of this subsidiary assertion.Other proofs quite similar (see book).

COMPLETING THE PROOFOnce we have proved:

Sender sat f(right) � SAPA

What can we say about S ′, where:

S ′ def= Sender � Medium � Receiver

By using rule Piping, we can deduce that:

(Sender � Medium � Receiver) sat (∃t· (∃s · (f(s) � SAPA

∧ (s � K � t � K) )∧ SAPB � f(t) )

From this, it follows from the definition of f that:

(Sender � Medium � Receiver) sat (SAPB � SAPA)

as required.Course 02221/02222, DTU, Spring 2008. – p. 15/2

3: SERVICES AND LAYERINGREVISITED

SERVICE FEATURESWhat kind of features might we want in a communication service?

A. Logical properties:Sequence preservation.Data Unit synchronisationFlow control.Freedom from error.Service reset.Connection establishment and release.Change of mode.Information about change of peer state.Expedited DataSecurity.

SERVICE FEATURESWhat kind of features might we want in a communication service?

A. Logical properties:Sequence preservation.Data Unit synchronisationFlow control.Freedom from error.Service reset.Connection establishment and release.Change of mode.Information about change of peer state.Expedited DataSecurity.

B. Technical/economic properties:PriceThroughputCapacity

SEQUENCE PRESERVATION�

�Sender

�Receiver�

Satisfies the CSP specification: S sat (cr � cs)

�Sender

�Receiver�

EXAMPLES:1. S def= (cs?x : M → (cr!x → S))

2. S def= (cs?x : M →(S[c/cr] ‖{c} (cr!x → BUF1)[c/cs]) \ {c} )

where BUF1 def= (cs?x : M → (cr!x → BUF1))

�Sender

�Receiver�

EXAMPLE OF NON-S.P. SERVICE:3. S def= (cs?x : M → S1[x])

where S1[x : M] def= (cs?y : M → (cr!y →(cs?y : M → (cr!x → S1[y]))))

DATA UNIT SYNCHRONISATION

BLOCK-ORIENTED or MESSAGE-ORIENTED service:One-to-one correspondence between blocks/messages passed toservice for transmission and messages delivered to receivers.

1234512345 Service

12345 Service

Cut anywhere

DATA UNIT SYNCHRONISATION

BLOCK-ORIENTED or MESSAGE-ORIENTED service:One-to-one correspondence between blocks/messages passed toservice for transmission and messages delivered to receivers.

1234512345 Service

12345 Service

Cut anywhere

STREAM-ORIENTED service:Boundaries between messages passed are not necessarilypreserved when data are delivered to receivers.

FREEDOM FROM ERROR

ERROR-FREE service:Delivers same messages as sent off. No corruption or loss.

BASIC ERROR MODEL: Sender takes part in communication event es

and receiver in event er. Receiver’s message buffer contentchanges from mr to m′

r.Four basic cases:

FREEDOM FROM ERROR

r.Four basic cases:1. FAULT-FREE communication:

es = cs!ms, er = cr?br, m′r = ms.

FREEDOM FROM ERROR

2. MESSAGE LOSS FAULT:es = cs!ms, er = nil, m′

r = mr.

FREEDOM FROM ERROR

r = mr.3. SPURIOUS MESSAGE FAULT:

es = nil, er = cr?br, m′r =???.

FREEDOM FROM ERROR

4. MESSAGE CORRUPTION FAULT:es = cs!ms, er = cr?br, m′

r �= ms.

FREEDOM FROM ERROR

4. MESSAGE CORRUPTION FAULT:es = cs!ms, er = cr?br, m′

r �= ms.More complex cases can be composed from these basic ones.

CONNECTION-MODECONNECTION-MODE service:Logical or physical channel is set up before real exchange of data cantake place. Channel is released when data transfer complete.So three phases of operation:

Connectionestablishment

Connectionreleasephase

User B

User ATime

Data transfer phase

CONNECTION-MODECONNECTION-MODE service:Logical or physical channel is set up before real exchange of data cantake place. Channel is released when data transfer complete.So three phases of operation:

Connectionestablishment

Connectionreleasephase

User B

User ATime

Data transfer phase

Initial exchange enables service users to establish their INITIAL GLOBAL

STATE, and to agree on parameters for data transfer phase, such as:Identities of the service users (names/addresses).Service facilities to be available.Syntax in which data will be transferred.Quality of Service (throughput, error rate,. . . ).

TWO-USER vs. MULTI-USER

POINT-TO-POINT services:Only two users!Maybe not equal opportunities for both, as service mayoffer:

SIMPLEX data transmissionHALF-DUPLEX data transmissionFULL DUPLEX data transmission

TWO-USER vs. MULTI-USER

POINT-TO-POINT services:Only two users!Maybe not equal opportunities for both, as service mayoffer:

SIMPLEX data transmissionHALF-DUPLEX data transmissionFULL DUPLEX data transmission

MULTI-PEER services:1-to-all (BROADCAST)

1-to-N (MULTICAST)

all-to-1 (INVERSE BROADCAST)

MULTI-PEER CONCEPTS

��

��i

Multi−peer service

Invoked group: Sub-set, I ⊆ U , of users that initiator tries to communicatewith.

Active group: Sub-set, A ⊆ I, of users with whom comm. takes place.

Static group: Group whose composition does not change during a singleinstance of communication (∼ connectionless transfer or lifetime ofconnection).

Dynamic group: Group whose composition can change during a singleinstance of communication.

Group integrity: Measure of extent to which a group’s composition satisfiessome agreed criterion (e.g. certain number of members present).

OSI LAYERING – AGAIN��

��(N+1)-entity

��

��(N+1)-entity�

(N)-SERVICE��

��(N)-entity

��

��(N)-entity�

��(N-1)-

SERVICE

�(N)-SAP �(N)-SAP

� �

(N)-SERVICE is offered at (N)-SAPs by cooperation between (N)-ENTITIES,which communicate by using an (N)-PROTOCOL,which relies on a (N-1)-SERVICE . . .

A “universal” model of a layered architecture.

CSP MODEL:

SNdef= PAN � SN−1 � PBN

= PAN � (PAN−1 � SN−2 � PBN−1) � PBN

and also = (PAN � PAN−1) � SN−2 � (PBN−1 � PBN)

OSI LAYERS

APPLICATIONDirect support to application processes.(File transfer, e-mail, virtual terminals, clock synchr.,. . . )

PRESENTATIONTransformation of data to syntactic form acceptable to A-entities.(Character sets, data structures,... )

SESSIONOrganisation of dialogues between cooperating P-entities.(Synchronisation points, roll-back, token control of dialogues)

TRANSPORTTransfer of data on end-to-end basis, hiding properties of network.(End-to-end sequence control, error control and flow control)

NETWORKTransfer of data between systems connected by arbitrary networks.(Routing, handling sub-networks)

DATA LINKTransfer of data blocks between directly connected systems.(Framing, error control/recovery, sequence control, flow control)

PHYSICALTransfer of physical data units (individual bits) between systems di-rectly connected via a medium.(Signalling on the physical medium)� PHYSICAL MEDIUM

INTERNET LAYERS

APPLICATIONDirect support to application processes.

(File transfer, e-mail, virtual terminals, clock synchr.,. . . )

TRANSPORTTransfer of data on end-to-end basis, such that properties ofthe underlying network are hidden.

(End-to-end sequence control, error control and flow control)

NETWORKTransfer of data between systems connected by arbitrary net-works, possibly with sub-networks.

(Routing, handling sub-networks)

DATA LINKTransfer of data blocks between systems directly connectedvia a medium.

(Framing, error control/recovery, sequence contr., flow contr.)

PHYSICALTransfer of physical data units (individual bits) between sys-tems directly connected via a medium.

(Signalling on the physical medium)

� PHYSICAL MEDIUMCourse 02221/02222, DTU, Spring 2008. – p. 26/2

PROTOCOLS

Don’t forget:

The service’s FACILITIES are produced by using the FUNCTIONSperformed by the PROTOCOL ENTITIES which collaborate toimplement the service.

��

USER A USER B

Underlying service

Protocol

Serviceinterface

Next week we shall look at some of the basic protocol functionsfor providing simple two-user service facilities.

protocols and services - dtu

Documents

emergency medical services treatment protocols

introduction to web services protocols

p&w engine services, inc. -...

services and protocols engineering -...

chapter other network protocols and services. other network...

gsm switching-services-and-protocols

revêtements de sol scellés - multi services · pdf file—...

schedule 4 services protocols and specifications …

communication gsm architecture, protocols and services

gsm - architecture, protocols and services

emergency medical services pre-hospital treatment protocols

middleware & web services. layered protocols: ip layers,...

technical feasibility of ancillary services provided by...

ebxml registry services and protocols version 3

[ms-storod]: storage services protocols overview

services provided by internet transport protocols

2003 prehospital patient care protocols vii. pediatric...

nursing services health and safety protocols purpose

[ms-authsod]: authentication services protocols overview

ohiohealth emergency medical services medical protocols ·...