protocols and services - dtu
TRANSCRIPT
Protocols and ServicesRobin [email protected]
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
Course 02221/02222, DTU, Spring 2008. – p. 2/2
VIEWS OF A SYSTEM
Most abstract view: Participating processes interact at a commonINTERACTION POINT, for example a shared channel:�
�
�
�Process A
�
�
�
�Process B�
IAB
Course 02221/02222, DTU, Spring 2008. – p. 3/2
VIEWS OF A SYSTEM
Most abstract view: Participating processes interact at a commonINTERACTION POINT, for example a shared channel:�
�
�
�Process A
�
�
�
�Process B�
IAB
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
Course 02221/02222, DTU, Spring 2008. – p. 3/2
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
�
�
�
�PA
�
�
�
�PB�
�
�
�SAB
�I ′AS
�I ′BS
Course 02221/02222, DTU, Spring 2008. – p. 4/2
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
�
�
�
�PA
�
�
�
�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 . . . .
Course 02221/02222, DTU, Spring 2008. – p. 4/2
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).
Course 02221/02222, DTU, Spring 2008. – p. 5/2
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.
Course 02221/02222, DTU, Spring 2008. – p. 6/2
2: PROVING PROPERTIES OF ACOMPOSED SERVICE
Course 02221/02222, DTU, Spring 2008. – p. 7/2
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)
Course 02221/02222, DTU, Spring 2008. – p. 8/2
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
c
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?
Course 02221/02222, DTU, Spring 2008. – p. 8/2
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!
Course 02221/02222, DTU, Spring 2008. – p. 9/2
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〉.
Course 02221/02222, DTU, Spring 2008. – p. 10/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〉.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.
Course 02221/02222, DTU, Spring 2008. – p. 11/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.
These look intuitively true! For example:
Sender�〈m1,m2,m3〉SAPA
�〈m1, ACK,m2, NACK,m2, ACK,m3, ACK〉right
Course 02221/02222, DTU, Spring 2008. – p. 11/2
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)
Course 02221/02222, DTU, Spring 2008. – p. 13/2
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).
Course 02221/02222, DTU, Spring 2008. – p. 14/2
COMPLETING THE PROOFOnce we have proved:
Sender sat f(right) � SAPA
Receiver sat SAPB � f(left)Medium sat left � K � right � K
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
Course 02221/02222, DTU, Spring 2008. – p. 16/2
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.
Course 02221/02222, DTU, Spring 2008. – p. 17/2
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
Course 02221/02222, DTU, Spring 2008. – p. 17/2
SEQUENCE PRESERVATION�
�
�
�Sender
�
�
�
�Receiver�
�
�
�S
�cs
�cr
Satisfies the CSP specification: S sat (cr � cs)
Course 02221/02222, DTU, Spring 2008. – p. 18/2
SEQUENCE PRESERVATION�
�
�
�Sender
�
�
�
�Receiver�
�
�
�S
�cs
�cr
Satisfies the CSP specification: S sat (cr � cs)
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))
Course 02221/02222, DTU, Spring 2008. – p. 18/2
SEQUENCE PRESERVATION�
�
�
�Sender
�
�
�
�Receiver�
�
�
�S
�cs
�cr
Satisfies the CSP specification: S sat (cr � cs)
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]))))
Course 02221/02222, DTU, Spring 2008. – p. 18/2
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
Course 02221/02222, DTU, Spring 2008. – p. 19/2
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.
Course 02221/02222, DTU, Spring 2008. – p. 19/2
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:
Course 02221/02222, DTU, Spring 2008. – p. 20/2
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:1. FAULT-FREE communication:
es = cs!ms, er = cr?br, m′r = ms.
Course 02221/02222, DTU, Spring 2008. – p. 20/2
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:1. FAULT-FREE communication:
es = cs!ms, er = cr?br, m′r = ms.
2. MESSAGE LOSS FAULT:es = cs!ms, er = nil, m′
r = mr.
Course 02221/02222, DTU, Spring 2008. – p. 20/2
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:1. FAULT-FREE communication:
es = cs!ms, er = cr?br, m′r = ms.
2. MESSAGE LOSS FAULT:es = cs!ms, er = nil, m′
r = mr.3. SPURIOUS MESSAGE FAULT:
es = nil, er = cr?br, m′r =???.
Course 02221/02222, DTU, Spring 2008. – p. 20/2
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:1. FAULT-FREE communication:
es = cs!ms, er = cr?br, m′r = ms.
2. MESSAGE LOSS FAULT:es = cs!ms, er = nil, m′
r = mr.3. SPURIOUS MESSAGE FAULT:
es = nil, er = cr?br, m′r =???.
4. MESSAGE CORRUPTION FAULT:es = cs!ms, er = cr?br, m′
r �= ms.
Course 02221/02222, DTU, Spring 2008. – p. 20/2
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:1. FAULT-FREE communication:
es = cs!ms, er = cr?br, m′r = ms.
2. MESSAGE LOSS FAULT:es = cs!ms, er = nil, m′
r = mr.3. SPURIOUS MESSAGE FAULT:
es = nil, er = cr?br, m′r =???.
4. MESSAGE CORRUPTION FAULT:es = cs!ms, er = cr?br, m′
r �= ms.More complex cases can be composed from these basic ones.
Course 02221/02222, DTU, Spring 2008. – p. 20/2
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
phase
Connectionreleasephase
User B
User ATime
Data transfer phase
Course 02221/02222, DTU, Spring 2008. – p. 21/2
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
phase
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,. . . ).
Course 02221/02222, DTU, Spring 2008. – p. 21/2
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
Course 02221/02222, DTU, Spring 2008. – p. 22/2
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)
Course 02221/02222, DTU, Spring 2008. – p. 22/2
MULTI-PEER CONCEPTS
���������
���������
������
������
������
������
���������
���������i
A
Multi−peer service
I
U
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).
Course 02221/02222, DTU, Spring 2008. – p. 23/2
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)
Course 02221/02222, DTU, Spring 2008. – p. 24/2
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
Course 02221/02222, DTU, Spring 2008. – p. 25/2
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
PA PB
Underlying service
Protocol
Serviceinterface
Next week we shall look at some of the basic protocol functionsfor providing simple two-user service facilities.
Course 02221/02222, DTU, Spring 2008. – p. 27/2